Skip to content

v0.13.0 — migrations select by whether your tests actually run them

Latest

Choose a tag to compare

@manuglopez manuglopez released this 02 Oct 17:38
d25feaf

Migrations select by whether your tests actually run them

Until 0.12, every test that used a database trait was credited with every table named in any migration. Any migration change ran the whole database suite, whichever table it touched. The table tracker also started after setUp(), so it never saw tables touched by trait setUps, factories in traits or seeding. That blind spot is why the blanket union was needed.

0.13 records what each test really queries, and asks what a change does to the test database:

  • A migration already squashed into the test connection's schema dump never runs in tests, so editing it selects nothing. --explain says so.
  • A pending migration runs in every fresh test database, so it selects every database test.
  • A schema-dump change selects every database test, unless only comments, whitespace or migration ids changed. A change to the set of migration names counts: squashing a data migration silently removes its rows from test databases.

Also new

  • schema_dump => 'per-table' (opt-in) narrows a dump change to the tests of the changed tables. It follows foreign keys in both directions, and triggers, routines and views.
  • Migrations in every directory the app loads them from: the migration_paths config, literal loadMigrationsFrom() calls, and stancl/tenancy's database/migrations/tenant.
  • A new file in a new subdirectory of a sibling directory (app/Console/Commands/Reports/…) selects the tests next to it.
  • Table tracking starts before any provider boots, any trait setUp or any seeding. It also works under the in-process extension.
  • The extractor understands unions, comma joins, multi-table TRUNCATE/UPDATE, DELETE … USING and aliases.
  • migrations => 'conservative' restores the old behaviour.

Costs, stated plainly

  • One full re-record on upgrade. Structural fingerprint keys change, and the digest moves from n3 to n4.
  • Recording overhead is about +1.5 to 2.5 s per million queries.
  • Known limits: tables read only through static caches, raw PDO, queries in a provider's register(), and stored functions called without FROM.