Files
breadcrumb-the-shire/tests/Console/ModuleCommandsTest.php

213 lines
6.7 KiB
PHP
Raw Permalink Normal View History

<?php
namespace MintyPHP\Tests\Console;
use MintyPHP\Console\Commands\Module\DeactivateCommand;
use MintyPHP\Console\Commands\Module\RuntimeSyncCommand;
use MintyPHP\Console\Runner\Module\ModuleRunnerInterface;
use PHPUnit\Framework\TestCase;
final class ModuleCommandsTest extends TestCase
{
public function testRuntimeSyncJsonOutputShapeAndExitCode(): void
{
$runner = new FakeModuleRunner();
$runner->runtimeSyncResult = [
'command' => 'module:sync',
'status' => 'ok',
'exit_code' => 0,
'vendor_warnings_ignored_total' => 2,
'duration_ms' => 88,
'steps' => [
feat(console): add db:migrate CLI for idempotent core schema updates Existing systems used to have no automatic mechanism for the db/updates/*.sql idempotent updates after `git pull` — devs had to remember which files were already applied and run new ones manually with `mariadb < ...`. Mirror module:migrate to fix this: - New `bin/console db:migrate` walks db/updates/*.sql in alphabetical order, skipping anything already recorded in the new core_migrations tracking table. Each file runs in its own transaction; failure rolls back so the file is retried on the next run. - New `db:migrate --status` lists applied vs. pending files without running anything. Useful for ops debugging "schema seems stale" symptoms. - module:sync now runs db:migrate as its first step, so the standard post-pull command stays a single invocation. README's 3-step setup is unchanged — module:sync now also covers core schema updates. CoreMigrationRepository owns its own mysqli connection (using the same DB credentials as MintyPHP\DB) and runs raw `$mysqli->query()` instead of going through DB::query's prepared statement path — MariaDB rejects some DDL (e.g. ALTER TABLE … ADD CONSTRAINT CHECK) in the prepared protocol, which the existing 18 db/updates files trip on. ModuleMigrationRepository is left untouched (no module migration uses such DDL today and changing the vendor pattern is out of scope). End-to-end verified: against an existing DB the first run applies all 19 idempotent files as no-ops and records them, second run reports "all updates already applied". Against a freshly init'd DB the same thing happens — no double work, no surprises. All encrypted seed secrets keep decrypting because APP_CRYPTO_KEY is unchanged. Tests: tests/Console/CoreCommandsTest covers success/failure/status output shapes against a FakeModuleRunner (mirror of the existing ModuleCommandsTest pattern). 5 stale baseline entries in phpstan-baseline removed (covered by the new @api annotation on the test fixture class). Docs: CLAUDE.md and docs/reference-cli-commands.md document the new command + --status flag; docs/howto-fehlerbehebung.md gains a "schema seems stale after git pull" section pointing at db:migrate --status. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-29 08:59:57 +02:00
'db-migrate' => ['status' => 'ok', 'exit_code' => 0, 'vendor_warnings_ignored' => 0],
'migrate' => ['status' => 'ok', 'exit_code' => 0, 'vendor_warnings_ignored' => 0],
'permissions-sync' => ['status' => 'ok', 'exit_code' => 0, 'vendor_warnings_ignored' => 1],
'build' => ['status' => 'ok', 'exit_code' => 0, 'vendor_warnings_ignored' => 0],
'assets-sync' => ['status' => 'ok', 'exit_code' => 0, 'vendor_warnings_ignored' => 1],
],
'message' => 'done',
];
$command = new RuntimeSyncCommand($runner);
ob_start();
$exitCode = $command->execute([], ['format' => 'json']);
$output = (string) ob_get_clean();
self::assertSame(0, $exitCode);
/** @var array<string, mixed> $decoded */
$decoded = json_decode($output, true, 512, JSON_THROW_ON_ERROR);
self::assertSame('module:sync', $decoded['command']);
self::assertSame('ok', $decoded['status']);
self::assertSame(0, $decoded['exit_code']);
self::assertArrayHasKey('steps', $decoded);
feat(console): add db:migrate CLI for idempotent core schema updates Existing systems used to have no automatic mechanism for the db/updates/*.sql idempotent updates after `git pull` — devs had to remember which files were already applied and run new ones manually with `mariadb < ...`. Mirror module:migrate to fix this: - New `bin/console db:migrate` walks db/updates/*.sql in alphabetical order, skipping anything already recorded in the new core_migrations tracking table. Each file runs in its own transaction; failure rolls back so the file is retried on the next run. - New `db:migrate --status` lists applied vs. pending files without running anything. Useful for ops debugging "schema seems stale" symptoms. - module:sync now runs db:migrate as its first step, so the standard post-pull command stays a single invocation. README's 3-step setup is unchanged — module:sync now also covers core schema updates. CoreMigrationRepository owns its own mysqli connection (using the same DB credentials as MintyPHP\DB) and runs raw `$mysqli->query()` instead of going through DB::query's prepared statement path — MariaDB rejects some DDL (e.g. ALTER TABLE … ADD CONSTRAINT CHECK) in the prepared protocol, which the existing 18 db/updates files trip on. ModuleMigrationRepository is left untouched (no module migration uses such DDL today and changing the vendor pattern is out of scope). End-to-end verified: against an existing DB the first run applies all 19 idempotent files as no-ops and records them, second run reports "all updates already applied". Against a freshly init'd DB the same thing happens — no double work, no surprises. All encrypted seed secrets keep decrypting because APP_CRYPTO_KEY is unchanged. Tests: tests/Console/CoreCommandsTest covers success/failure/status output shapes against a FakeModuleRunner (mirror of the existing ModuleCommandsTest pattern). 5 stale baseline entries in phpstan-baseline removed (covered by the new @api annotation on the test fixture class). Docs: CLAUDE.md and docs/reference-cli-commands.md document the new command + --status flag; docs/howto-fehlerbehebung.md gains a "schema seems stale after git pull" section pointing at db:migrate --status. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-29 08:59:57 +02:00
self::assertArrayHasKey('db-migrate', $decoded['steps']);
self::assertArrayHasKey('migrate', $decoded['steps']);
self::assertArrayHasKey('assets-sync', $decoded['steps']);
}
public function testRuntimeSyncInvalidFormatReturnsOne(): void
{
$command = new RuntimeSyncCommand(new FakeModuleRunner());
$exitCode = $command->execute([], ['format' => 'xml']);
self::assertSame(1, $exitCode);
}
public function testDeactivateDoesNotMutateGlobalArgvAndPassesOptions(): void
{
$runner = new FakeModuleRunner();
$runner->deactivateResult = [
'command' => 'module:deactivate',
'status' => 'ok',
'exit_code' => 0,
'vendor_warnings_ignored' => 0,
'message' => 'ok',
];
$command = new DeactivateCommand($runner);
$argvBefore = ['bin/console', 'list'];
$GLOBALS['argv'] = $argvBefore;
$exitCode = $command->execute(['addressbook'], ['confirm' => true]);
self::assertSame(0, $exitCode);
self::assertSame('addressbook', $runner->deactivateModuleId);
self::assertTrue($runner->deactivateConfirm);
self::assertFalse($runner->deactivateDryRun);
self::assertSame($argvBefore, $GLOBALS['argv']);
}
}
feat(console): add db:migrate CLI for idempotent core schema updates Existing systems used to have no automatic mechanism for the db/updates/*.sql idempotent updates after `git pull` — devs had to remember which files were already applied and run new ones manually with `mariadb < ...`. Mirror module:migrate to fix this: - New `bin/console db:migrate` walks db/updates/*.sql in alphabetical order, skipping anything already recorded in the new core_migrations tracking table. Each file runs in its own transaction; failure rolls back so the file is retried on the next run. - New `db:migrate --status` lists applied vs. pending files without running anything. Useful for ops debugging "schema seems stale" symptoms. - module:sync now runs db:migrate as its first step, so the standard post-pull command stays a single invocation. README's 3-step setup is unchanged — module:sync now also covers core schema updates. CoreMigrationRepository owns its own mysqli connection (using the same DB credentials as MintyPHP\DB) and runs raw `$mysqli->query()` instead of going through DB::query's prepared statement path — MariaDB rejects some DDL (e.g. ALTER TABLE … ADD CONSTRAINT CHECK) in the prepared protocol, which the existing 18 db/updates files trip on. ModuleMigrationRepository is left untouched (no module migration uses such DDL today and changing the vendor pattern is out of scope). End-to-end verified: against an existing DB the first run applies all 19 idempotent files as no-ops and records them, second run reports "all updates already applied". Against a freshly init'd DB the same thing happens — no double work, no surprises. All encrypted seed secrets keep decrypting because APP_CRYPTO_KEY is unchanged. Tests: tests/Console/CoreCommandsTest covers success/failure/status output shapes against a FakeModuleRunner (mirror of the existing ModuleCommandsTest pattern). 5 stale baseline entries in phpstan-baseline removed (covered by the new @api annotation on the test fixture class). Docs: CLAUDE.md and docs/reference-cli-commands.md document the new command + --status flag; docs/howto-fehlerbehebung.md gains a "schema seems stale after git pull" section pointing at db:migrate --status. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-29 08:59:57 +02:00
/**
* @api Test fixture public properties are mutated by test cases across files.
*/
final class FakeModuleRunner implements ModuleRunnerInterface
{
/** @var array<string, mixed> */
public array $runtimeSyncResult = [
'command' => 'module:sync',
'status' => 'ok',
'exit_code' => 0,
'vendor_warnings_ignored_total' => 0,
'duration_ms' => 0,
'steps' => [
feat(console): add db:migrate CLI for idempotent core schema updates Existing systems used to have no automatic mechanism for the db/updates/*.sql idempotent updates after `git pull` — devs had to remember which files were already applied and run new ones manually with `mariadb < ...`. Mirror module:migrate to fix this: - New `bin/console db:migrate` walks db/updates/*.sql in alphabetical order, skipping anything already recorded in the new core_migrations tracking table. Each file runs in its own transaction; failure rolls back so the file is retried on the next run. - New `db:migrate --status` lists applied vs. pending files without running anything. Useful for ops debugging "schema seems stale" symptoms. - module:sync now runs db:migrate as its first step, so the standard post-pull command stays a single invocation. README's 3-step setup is unchanged — module:sync now also covers core schema updates. CoreMigrationRepository owns its own mysqli connection (using the same DB credentials as MintyPHP\DB) and runs raw `$mysqli->query()` instead of going through DB::query's prepared statement path — MariaDB rejects some DDL (e.g. ALTER TABLE … ADD CONSTRAINT CHECK) in the prepared protocol, which the existing 18 db/updates files trip on. ModuleMigrationRepository is left untouched (no module migration uses such DDL today and changing the vendor pattern is out of scope). End-to-end verified: against an existing DB the first run applies all 19 idempotent files as no-ops and records them, second run reports "all updates already applied". Against a freshly init'd DB the same thing happens — no double work, no surprises. All encrypted seed secrets keep decrypting because APP_CRYPTO_KEY is unchanged. Tests: tests/Console/CoreCommandsTest covers success/failure/status output shapes against a FakeModuleRunner (mirror of the existing ModuleCommandsTest pattern). 5 stale baseline entries in phpstan-baseline removed (covered by the new @api annotation on the test fixture class). Docs: CLAUDE.md and docs/reference-cli-commands.md document the new command + --status flag; docs/howto-fehlerbehebung.md gains a "schema seems stale after git pull" section pointing at db:migrate --status. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-29 08:59:57 +02:00
'db-migrate' => ['status' => 'ok', 'exit_code' => 0, 'vendor_warnings_ignored' => 0],
'migrate' => ['status' => 'ok', 'exit_code' => 0, 'vendor_warnings_ignored' => 0],
'permissions-sync' => ['status' => 'ok', 'exit_code' => 0, 'vendor_warnings_ignored' => 0],
'build' => ['status' => 'ok', 'exit_code' => 0, 'vendor_warnings_ignored' => 0],
'assets-sync' => ['status' => 'ok', 'exit_code' => 0, 'vendor_warnings_ignored' => 0],
],
'message' => 'ok',
];
feat(console): add db:migrate CLI for idempotent core schema updates Existing systems used to have no automatic mechanism for the db/updates/*.sql idempotent updates after `git pull` — devs had to remember which files were already applied and run new ones manually with `mariadb < ...`. Mirror module:migrate to fix this: - New `bin/console db:migrate` walks db/updates/*.sql in alphabetical order, skipping anything already recorded in the new core_migrations tracking table. Each file runs in its own transaction; failure rolls back so the file is retried on the next run. - New `db:migrate --status` lists applied vs. pending files without running anything. Useful for ops debugging "schema seems stale" symptoms. - module:sync now runs db:migrate as its first step, so the standard post-pull command stays a single invocation. README's 3-step setup is unchanged — module:sync now also covers core schema updates. CoreMigrationRepository owns its own mysqli connection (using the same DB credentials as MintyPHP\DB) and runs raw `$mysqli->query()` instead of going through DB::query's prepared statement path — MariaDB rejects some DDL (e.g. ALTER TABLE … ADD CONSTRAINT CHECK) in the prepared protocol, which the existing 18 db/updates files trip on. ModuleMigrationRepository is left untouched (no module migration uses such DDL today and changing the vendor pattern is out of scope). End-to-end verified: against an existing DB the first run applies all 19 idempotent files as no-ops and records them, second run reports "all updates already applied". Against a freshly init'd DB the same thing happens — no double work, no surprises. All encrypted seed secrets keep decrypting because APP_CRYPTO_KEY is unchanged. Tests: tests/Console/CoreCommandsTest covers success/failure/status output shapes against a FakeModuleRunner (mirror of the existing ModuleCommandsTest pattern). 5 stale baseline entries in phpstan-baseline removed (covered by the new @api annotation on the test fixture class). Docs: CLAUDE.md and docs/reference-cli-commands.md document the new command + --status flag; docs/howto-fehlerbehebung.md gains a "schema seems stale after git pull" section pointing at db:migrate --status. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-29 08:59:57 +02:00
/** @var array<string, mixed> */
public array $dbMigrateResult = [
'command' => 'db:migrate',
'status' => 'ok',
'exit_code' => 0,
'vendor_warnings_ignored' => 0,
'message' => 'db-migrate: all updates already applied.',
];
/** @var array<string, mixed> */
public array $dbMigrateStatusResult = [
'command' => 'db:migrate --status',
'applied' => [],
'pending' => [],
];
/** @var array<string, mixed> */
public array $deactivateResult = [
'command' => 'module:deactivate',
'status' => 'ok',
'exit_code' => 0,
'vendor_warnings_ignored' => 0,
'message' => 'ok',
];
public string $deactivateModuleId = '';
public bool $deactivateConfirm = false;
public bool $deactivateDryRun = false;
feat(console): add db:migrate CLI for idempotent core schema updates Existing systems used to have no automatic mechanism for the db/updates/*.sql idempotent updates after `git pull` — devs had to remember which files were already applied and run new ones manually with `mariadb < ...`. Mirror module:migrate to fix this: - New `bin/console db:migrate` walks db/updates/*.sql in alphabetical order, skipping anything already recorded in the new core_migrations tracking table. Each file runs in its own transaction; failure rolls back so the file is retried on the next run. - New `db:migrate --status` lists applied vs. pending files without running anything. Useful for ops debugging "schema seems stale" symptoms. - module:sync now runs db:migrate as its first step, so the standard post-pull command stays a single invocation. README's 3-step setup is unchanged — module:sync now also covers core schema updates. CoreMigrationRepository owns its own mysqli connection (using the same DB credentials as MintyPHP\DB) and runs raw `$mysqli->query()` instead of going through DB::query's prepared statement path — MariaDB rejects some DDL (e.g. ALTER TABLE … ADD CONSTRAINT CHECK) in the prepared protocol, which the existing 18 db/updates files trip on. ModuleMigrationRepository is left untouched (no module migration uses such DDL today and changing the vendor pattern is out of scope). End-to-end verified: against an existing DB the first run applies all 19 idempotent files as no-ops and records them, second run reports "all updates already applied". Against a freshly init'd DB the same thing happens — no double work, no surprises. All encrypted seed secrets keep decrypting because APP_CRYPTO_KEY is unchanged. Tests: tests/Console/CoreCommandsTest covers success/failure/status output shapes against a FakeModuleRunner (mirror of the existing ModuleCommandsTest pattern). 5 stale baseline entries in phpstan-baseline removed (covered by the new @api annotation on the test fixture class). Docs: CLAUDE.md and docs/reference-cli-commands.md document the new command + --status flag; docs/howto-fehlerbehebung.md gains a "schema seems stale after git pull" section pointing at db:migrate --status. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-29 08:59:57 +02:00
public function dbMigrate(): array
{
return $this->dbMigrateResult;
}
public function dbMigrateStatus(): array
{
return $this->dbMigrateStatusResult;
}
public function migrate(): array
{
return [
'command' => 'module:migrate',
'status' => 'ok',
'exit_code' => 0,
'vendor_warnings_ignored' => 0,
'message' => 'ok',
];
}
public function permissionsSync(): array
{
return [
'command' => 'module:permissions-sync',
'status' => 'ok',
'exit_code' => 0,
'vendor_warnings_ignored' => 0,
'created' => 0,
'updated' => 0,
'unchanged' => 0,
'deactivated' => 0,
'total' => 0,
'message' => 'ok',
];
}
public function build(): array
{
return [
'command' => 'module:build',
'status' => 'ok',
'exit_code' => 0,
'vendor_warnings_ignored' => 0,
'core_entries' => 0,
'module_entries' => 0,
'message' => 'ok',
];
}
public function assetsSync(): array
{
return [
'command' => 'module:assets-sync',
'status' => 'ok',
'exit_code' => 0,
'vendor_warnings_ignored' => 0,
'mode' => 'symlink',
'created' => 0,
'updated' => 0,
'removed' => 0,
'unchanged' => 0,
'message' => 'ok',
];
}
public function deactivate(string $moduleId, bool $confirm, bool $dryRun): array
{
$this->deactivateModuleId = $moduleId;
$this->deactivateConfirm = $confirm;
$this->deactivateDryRun = $dryRun;
return $this->deactivateResult;
}
public function runtimeSync(): array
{
return $this->runtimeSyncResult;
}
}