Migrácie na reálnej databáze

Štrukturálna kontrola je nezávislá od enginu; definitívny dôkaz však spustí migrácie proti živej databáze. Slúžia na to dve expectations — spúšťač a jeho negatívna kontrola:

expect($migrationsDir)->toApplyOnConnection(string $connection, ?int $migrations = null);
expect($migrationsDir)->toRejectBrokenOrderOnConnection(Closure $reorder, string $connection);

it('applies on postgres', function (): void {
    expect(database_path('migrations'))->toApplyOnConnection('pgsql', migrations: 14);
})->skip(fn (): bool => ! test()->connectionAvailable('pgsql'), 'no postgres');

it('rejects a broken order on postgres', function (): void {
    expect(database_path('migrations'))->toRejectBrokenOrderOnConnection(
        fn (array $files): array => array_reverse($files),
        'pgsql',
    );
})->skip(fn (): bool => ! test()->connectionAvailable('pgsql'), 'no postgres');

Negatívna kontrola

Zelený test cudzích kľúčov nič nedokazuje, kým nevidíte, že engine chybné poradie odmietne. toRejectBrokenOrderOnConnection prejde len vtedy, ak engine preusporiadanú sadu odmietne, a hlasno zlyhá, ak ju prijme — driver, ktorý cudzie kľúče nevynucuje (napríklad SQLite), by z kontroly urobil prázdne gesto. Closure $reorder dostane zoradené súbory migrácií a musí vrátiť ich permutáciu; vynechanie, pridanie alebo premenovanie súboru aserciu zhodí.

Odmietnutie sa počíta, len ak ide o chybu poradia: chýbajúcu tabuľku či stĺpec alebo cudzí kľúč, ktorý engine nedokázal vytvoriť. Sada, ktorá zlyhá v akomkoľvek poradí (neplatné SQL, chyba oprávnení), negatívnu kontrolu namiesto úspechu zhodí.

Poistky spúšťača

• migrations: pripne počet súborov, takže kontrola neprejde nad prázdnym ani presunutým adresárom.
• Sada, ktorá sa aplikuje bez vytvorenia jedinej tabuľky, zlyhá — aj prázdne up() sa „aplikuje čisto“.
• Obe asercie zlyhajú na engine, ku ktorému sa nedostanú — hlásenie „connection refused“ by sa inak tvárilo ako „engine poradie odmietol“. Podmieňte ich namiesto spoliehania sa, že engine beží.
• Spúšťač na čas behu nasmeruje predvolené pripojenie na cieľ, pred behom aj po ňom cieľ vyčistí a vždy obnoví pôvodné predvolené pripojenie — aj po behu, ktorý sa nepodarilo spustiť.

Keďže spúšťač na cieľovom pripojení maže všetky tabuľky, nasmerujte ho výhradne na vyhradenú testovaciu databázu. Po DriverMatrix::configure() sú pripojenia pgsql a mysql izolované sondy vo vlastnej schéme či databáze testing_probe, takže beh sondy sa k tabuľkám samotnej sady nikdy nedostane.

Viditeľné preskočenie — a počítanie preskočených

Obe asercie podmieňte cez connectionAvailable() (na PackageTestCase) alebo MigrationRunner::connectionIsAvailable() (kdekoľvek), aby sa beh bez Postgresu viditeľne preskočil namiesto zlyhania na nedostupnom engine:

use RoundlyConsulting\Testing\Assertions\Migrations\MigrationRunner;

// Without PackageTestCase, gate on the runner's own availability probe.
it('applies on postgres', function (): void {
    expect(database_path('migrations'))->toApplyOnConnection('pgsql', migrations: 14);
})->skip(fn (): bool => ! MigrationRunner::connectionIsAvailable('pgsql'), 'no postgres');

Sledujte počet preskočených testov, nie farbu. Tieto podmienky test preskočia, keď je engine nedostupný, takže zle nastavená CI vetva hlási zelenú bez jedinej overenej veci. Vo vetve, ktorá existuje práve kvôli nim, musí byť počet preskočených nulový.

Migrácie len dopredu

Nič v tomto balíku od vás nevyžaduje metódu down(). Roundly balíky migrujú len dopredu — cesta späť je mŕtvy kód, ktorý sa rozíde s up() — preto tu zámerne nie je žiadna asercia rollbacku. Odinštalovanie balíka je vecou hostiteľskej aplikácie: zmaže tabuľky, ktoré balík dokumentuje.