Data integrity test cases, because a constraint in code is not a constraint

The single idea running through this set is that a rule enforced only in application code is not enforced. Uniqueness checked by selecting before inserting will admit duplicates the moment two requests arrive together. Referential integrity maintained by remembering to delete children first will produce orphans as soon as a new code path forgets. A status column constrained only by validation will accept anything a migration, an admin tool or a direct write chooses to put there. Each of these is testable in one case, and each produces damage that is silent at the time and permanent afterwards, because there is no error to alert anyone and the resulting rows look entirely reasonable.

Concurrency is where the gap between intent and enforcement becomes visible. A read modify write cycle loses updates, drops counter increments and permits balances to go negative, and none of it appears in sequential testing because sequential testing never creates the overlap. The correct forms are a conditional update, an atomic increment or a constraint, and the test is to fire the operations simultaneously and then check the arithmetic rather than checking that no error was returned. Deadlocks belong in the same group: they will happen, so the requirement is that the losing transaction is retried safely and that the retry does not apply the same change twice.

Migrations are the highest risk routine activity in most systems. They need testing forwards against production scale data, they need a rollback path or an explicit acknowledgement that there is none, and they need to be safe while the previous application version is still serving traffic, which means old and new code must both work against the intermediate schema. Backfills need to be rerunnable, because they get interrupted, and a backfill that reprocesses rows on the second run is as damaging as one that skips them.

Finally, two operational cases that get assumed rather than verified. Soft delete is a filter, and a filter applied in the main query and forgotten in a report, an export or a uniqueness check brings the record back, which is a data exposure rather than a bug. And a backup is not a backup until it has been restored: a backup job reporting success proves that a file was written, not that the data in it can be recovered inside the recovery time objective. Timing an actual restore into a clean environment is the only version of that test which means anything.