Testing and safety

Every check here answers one question and no more than one. Knowing which question a green result answered is the difference between a gate and a habit.

Checks

Test migrations and schemasRun cases against throwaway databases and assert what the change did, not only that it ran.

Run checks in CITurn those checks into a pull-request gate, and read the exit codes correctly.

Lint migration SQLCatch destructive and backward-incompatible statements before a database sees them.

Validate a schema fileFail on a structural problem, or on a declaration a target would silently drop.

Report security findingsSurface privilege, owner and role findings in the desired schema.

Keep history verifiableWhat the integrity file proves, and what it does not.

What each answer covers

A test asserts a change’s effect on a throwaway database. A lint finding is about the SQL as written, with no database involved. Validation is about the desired schema alone. None of them observes the database you are about to change, which is what drift detection is for.

So a green pull request means the change is correct in isolation. Whether the target is in the state the change assumes is a separate question, asked against that target.

Choose the database

Use a throwaway database for tests, a dev or shadow database for replay and planning, and a reviewed target URL for a real apply. These roles are not interchangeable, and database URLs and dev databases defines each one.

Reference

Exit codes is the automation contract, lint rules enumerates every rule identifier, and test cases is the exact case format.