Cakephp Test Suite Light Laravel Package

Getting Started

composer require --dev vierge-noire/cakephp-test-suite-light

• Requires an existing CakePHP app with a working phpunit.xml and Datasources in config/app.php. There is no plugin to bin/cake plugin load — this is a dev-only test bootstrap.
• Wire it in tests/bootstrap.php: require Composer's autoloader, then the package's bootstrap.php (see the package src/ / README for the exact path, e.g. vendor/vierge-noire/cakephp-test-suite-light/bootstrap.php). That require is what installs the fixture/transaction hooks and triggers creation of the <connection>_test database on first run.
• Make sure phpunit.xml uses bootstrap="tests/bootstrap.php" and that the default Datasources entry has a test counterpart (standard CakePHP <dbname>_test convention).
• Ensure the DB user can create/drop databases, or pre-create the _test database manually. The first run is where most setup pain lives.
• First use case: take one existing integration test that declares $fixtures, run vendor/bin/phpunit tests/TestCase/Controller/ArticlesControllerTest.php, and time it. Then run a control test extending plain Cake\TestSuite\TestCase to confirm the speedup. You should see schema loaded once, fixtures loaded once, and each test wrapped in a transaction that is rolled back.
• Where to look first: tests/bootstrap.php, phpunit.xml, config/app.php Datasources, then the package's src/ (bootstrap.php, connection helper, test listener) — the README is short and the source is the real documentation.

Implementation Patterns

• Centralize setup in tests/TestCase.php. Let it extend the normal CakePHP test case and let the package hooks do the work; do not override setUp/tearDown in a way that commits or truncates.
• Keep declaring $fixtures as usual. The plugin changes when/how often they load (once at suite start) and relies on rollback for per-test isolation, so fixture declarations still matter for data availability.
• Seed per test freely: factories (cakephp-fixture-factories, Faker) or Table::newEntity() + saveOrFail() in setUp() are cheap because the insert is rolled back. Prefer this over ever-growing static fixtures.
• Multi-datasource apps: every Datasources entry used in tests needs a test variant; the package tracks transactions per connection/savepoint.
• CI pattern: cache vendor/ but never cache the _test database. Add a DROP DATABASE IF EXISTS <name>_test step before the suite if a previous job can leave it dirty, then let the bootstrap recreate it.
• Debug pattern: when a test fails only in the full suite, run it alone with --filter testWhatever --debug. Pass alone + fail in suite almost always means leaked state from a committed transaction.
• Opt-out pattern: tests that need DDL, migrations, or a truly pristine DB should extend plain Cake\TestSuite\TestCase (or a small NoTransactionTrait marker) so the transaction wrapper doesn't interfere.
• Parallel test runs: give each worker its own _test database name. Multiple workers sharing one database defeats the isolation model.
• Compatibility note: CakePHP 4.3+ ships a native Cake\TestSuite\Fixture\TransactionStrategy. If that is enough for you, the plugin's remaining value is mostly one-time schema/fixture loading and convenience bootstrap; evaluate before adding a dependency.

Gotchas and Tips

• Schema drift is the #1 failure mode. After adding migrations, the plugin may not detect the change and tests run against an old schema. Drop/rebuild the _test database after migration changes, and treat it as disposable.
• Any explicit commit(), DDL (CREATE/ALTER/DROP), or transaction opened outside the package's savepoints breaks rollback and leaks data into later tests. Audit fixture/factory code and application code that manages transactions.
• Do not use truncate() or deleteAll() in fixtures or teardown. It defeats the purpose, and TRUNCATE implicitly commits on MySQL, which can corrupt the strategy's state.
• Foreign-key load order still matters at suite start; cyclic FKs can fail the one-and-only fixture load even though per-test loading used to hide it.
• PHPUnit compatibility is a real risk: the package hooks the PHPUnit lifecycle, and PHPUnit 10 removed test listeners. Check the release's composer.json before upgrading PHPUnit or CakePHP. Last release being Oct 2023 with ~13 stars means low maintenance — pin versions and be ready to fork.
• SQLite behaves differently from MySQL/Postgres for transactions and DDL. If CI uses SQLite and you develop on MySQL, isolation behavior can diverge; prefer the same engine as production.
• Bootstrap errors are easy to miss. If the _test database isn't created, confirm credentials and that the app's default connection is reachable; run one test with -v to surface the bootstrap exception.
• Extension points worth reading in src/: the connection helper (how the _test name is derived and created), any Configure::write('TestSuiteLight', [...])-style options for enabling/cleanup behavior, and the listener — those are where you customize database naming or disable behavior per environment.
• Don't ship it to production: it's --dev, and the bootstrap assumes a disposable test database. Keep it out of production autoload paths and CI secrets that point at real data.