database-testinglisted

# Database Testing ## Why this matters even if you're "just" a UI/API tester The UI and API can both lie (cached, optimistic-UI, stale). The database is the source of truth. Before filing "data wasn't saved," check the actual row. ## Core checks - **CRUD correctness**: create persists all fields with correct types/defaults; read returns exactly what was written (no silent truncation/encoding issues); update touches only intended fields (no accidental overwrite of untouched columns); delete behaves as documented (hard vs soft — check for a `deleted_at`/`is_deleted` column before assuming hard delete). - **Constraints**: NOT NULL, UNIQUE, CHECK, foreign keys actually enforced — try to violate them directly (not just through the app) to confirm the DB itself protects integrity, not only application code. - **Referential integrity**: deleting a parent — does it cascade, restrict, or orphan children? Verify it matches the intended business rule, not just "doesn't error." - **Transactions**: multi-step operations either fully commit or fully roll back on failure — kill/interrupt mid-transaction (or simulate via a forced error) and confirm no partial state persists. - **Concurrency**: two simultaneous writes to the same row — last-write-wins silently, or optimistic locking (version column) rejecting the stale write? Test with genuinely concurrent requests, not sequential ones with a sleep. - **Deadlocks**: under concurrent load touching overlapping rows, does the DB/app handle a d