Dunit Laravel Package

Product Decisions This Supports

• Test-tooling build vs buy vs borrow. DUnit is a focused abstraction over PHPUnit/PDO: table assertions, dataset fixtures, isolation helpers — now bundled with a Docker-based test runner (dunit --pull, curated images). It remains a strong reference design when deciding whether to write in-house database assertion helpers, adopt a maintained fixture library, or fork an existing one.
• Repository / DAO layer investment. The table-assertion model (compare actual rows to an expected dataset) is a concrete pattern for making repository and query tests state-based rather than mock-based — less brittle, easier to review.
• Fixture strategy standardization. Decision on how test databases get seeded and reset across the suite (dataset fixtures vs. factories vs. raw seeders). DUnit represents the "dataset fixture" camp and helps scope the tradeoffs.
• Test environment reproducibility (new consideration). v2.1.0's Docker image management (--pull to refresh images, reworked and squashed default images, a php-nightly build) makes DUnit a data point for the "containerized, pinned test runtime vs. run-on-host" decision. This is now as much an environment-provisioning question as an assertion-library one.
• Migration and schema-change testing. Supports asserting post-migration state, which informs whether migration tests become part of the CI gate or remain manual.
• Roadmap for CI reliability. Table assertions plus pre-pulled, pinned images reduce flaky, over-mocked and environment-drift failures; feeds a "reduce test flake / speed up feedback" initiative.
• Legacy modernization sequencing. For older PHP services, knowing which historical testing patterns exist helps plan incremental test backfill without a full framework rewrite.

When to Consider This Package

Consider it when:

• The stack is PHP + PHPUnit + a PDO-compatible database, and the team wants lightweight table-level assertions without a heavy fixture framework.
• You also want a pre-baked, pinned container runtime for tests. The php-nightly image and the reworked, smaller Debian-based images show the project treats the runtime as part of the product — useful if you are standardizing dev/CI parity.
• You are evaluating or prototyping a fixture/assertion layer and want a compact, readable reference implementation to copy the API shape from.
• You are willing to fork and own the code: MIT-licensed and small, so the value is in the design and the source, not upstream support.
• The scope is a short-lived or internal tool where pinning an old dependency is acceptable.

Look elsewhere when:

• It would become a long-lived production dependency. v2.1.0 shows continued fixes and features, but the release content (PHP 7 beta nightly image, $COLUMNS and Ctrl+C handling) dates the line to the PHP 7 era. Verify maintenance status before assuming otherwise; treat it as unmaintained-until-proven-active, with no security-patch, PHP 8 compatibility, or response-time guarantees.
• Your team runs a modern Laravel stack. Laravel already ships RefreshDatabase, transactions, and assertDatabaseHas-style assertions; the marginal value is low and the integration/upgrade cost is real.
• You cannot run Docker in CI, or your images/policy are centrally managed — the Docker runner is a feature only if you can use it. The new --pull behavior also implies network access to a registry during test setup, which some pipelines forbid.
• You need active community support, documented upgrade paths, or vendor SLAs.
• Schema or platform requirements have moved on (non-PDO drivers, modern driver-specific types, parallel test execution) where the package has no coverage.

Caveat introduced by this release: the shipped defaults now include a PHP 7 beta image. Do not adopt the default image matrix as-is; audit and pin images to versions you support, and confirm the Docker runner behaves under your signal/timeout handling (v2.1.0 fixed Ctrl+C handling, so pin ≥ 2.1.0 if you use the CLI runner).

How to Pitch It (Stakeholders)

For executives (one-liner): DUnit is a small, MIT-licensed database testing helper — table assertions and dataset fixtures — that also packages a Docker-based test runner; the new 2.1.0 release adds image-pull convenience, smaller base images, and reliability fixes, but the tooling is still rooted in the PHP 7 era, so we treat it as a design reference or fork candidate, not a dependency we adopt outright. Low cost to evaluate, meaningful reduction in test maintenance if the pattern fits.

For engineering leads: The package offers table assertions, dataset fixtures, and isolation helpers on PHPUnit/PDO, plus a CLI runner that can pull and use curated Docker images. v2.1.0 is a real but incremental release — signal handling, $COLUMNS/progress-output fixes, dunit --pull, a php-nightly image, and markedly slimmer default images. That argues for a time-boxed spike: fork the repo, verify it against our PHP versions and drivers, and either maintain the fork internally or reimplement its assertion API (a day or two) inside our own test utilities. If we do use the runner, pin ≥ 2.1.0 for the Ctrl+C fix and replace the PHP 7 beta image with a version we support.

For the wider team: Tests that compare real table contents to expected datasets catch query and migration regressions that mocks miss. DUnit demonstrates the ergonomics we want, and the 2.1.0 release shows it also cares about reproducible test runtimes; we will reproduce that ergonomics in a small internal helper and pin our own images rather than depend on the upstream package.