Dunit Laravel Package

Technical Evaluation

• Architecture fit: DUnit remains a test-only dependency operating at the PHPUnit/database-test harness layer, not in Laravel application runtime. Its PDO-based table assertions and data-set fixtures still conceptually fit repository, query, and migration tests. However, the base-class integration model remains structurally misaligned with modern Laravel testing centered on Illuminate\Foundation\Testing\TestCase, RefreshDatabase, factories, seeders, and native database assertions. v2.1.0 adds Docker image orchestration and terminal/CI ergonomics, but does not add Laravel integration.
• Integration feasibility: Low for a current Laravel/PHP stack; medium only for a legacy suite already using DUnit and a Dockerized test runner. A compatibility spike remains mandatory. The new php-nightly image is explicitly PHP 7 beta, which reinforces that v2.1.0 is still aimed at a legacy PHP/PHPUnit era rather than modern Laravel versions.
• Technical risk: High lifecycle risk despite the new release. v2.1.0 partially mitigates prior abandonment concerns by fixing Ctrl+C handling and $COLUMNS, adding dunit --pull, and shrinking default images, but core risks remain: PHPUnit class/API compatibility, PHP version constraints, base-class conflicts with Laravel’s test case, database-specific assertion behavior, and supply-chain/CI risk. The Docker runner also introduces new operational dependencies: Docker availability, registry access, image pinning, and pull behavior.
• TPM recommendation: Do not adopt DUnit as a new strategic dependency for Laravel work. v2.1.0 may justify a short reevaluation if a team already runs DUnit in a bounded legacy Dockerized suite, but it does not change the recommendation for new Laravel tests. Prefer Laravel-native assertions and isolation helpers. Use DUnit as a reference for database-state assertion patterns or as a short-term bridge in legacy coverage unless a fork is explicitly funded and owned.
• Key questions: Which Laravel, PHP, PHPUnit/Pest, PDO driver, and Docker versions must be supported? Is the goal to preserve existing DUnit tests or introduce new database assertions? Can the team accept an internal fork? Which databases and CI topologies must pass? Will CI use dunit --pull, and how will images be pinned/cached? Will php-nightly be excluded in favor of stable pinned images? Are parallel test execution, large fixture volumes, and cancellation behavior required? Who owns compatibility and security patching?

Integration Approach

• Stack fit: Treat DUnit as require-dev only, pinned to an exact version, with no expectation of Laravel auto-discovery. Validate against the target PHPUnit API before committing. If the base class is incompatible, wrap only the useful assertion/data-set behavior behind a small internal trait or helper rather than inheriting from DUnit directly. If using v2.1.0’s Docker runner, treat Docker as part of the test toolchain and pin images rather than relying on mutable tags or php-nightly.
• Migration path: For existing DUnit suites, preserve behavior first with a compatibility fork or shim, then progressively replace brittle table comparisons with Laravel-native assertDatabaseHas/assertDatabaseMissing, schema assertions, factories, and seeders. For new tests, start with Laravel’s RefreshDatabase or transaction strategy and use DUnit-style table comparison only where it adds clear value. v2.1.0’s --pull feature should be adopted, if at all, with explicit image pinning and CI caching policy.
• Compatibility: Verify PHP version, PHPUnit version, PDO driver, database engine, Laravel test bootstrapping, Docker engine, registry access, and CI terminal behavior. Pay special attention to SQLite/MySQL/PostgreSQL differences, fixture ordering, column type normalization, CI database reset behavior, and the new signal-handling/$COLUMNS fixes. Avoid coupling core test infrastructure to DUnit until the spike passes.
• Sequencing:
  1. Run a one-day compatibility spike on the target stack with a single repository/query test, including Docker execution if the team intends to use the runner.
  2. Pin DUnit to v2.1.0 or the required fork and pin all Docker images; exclude php-nightly from standard CI.
  3. Isolate DUnit behind an internal test helper so application tests do not inherit directly from its base class.
  4. Pilot on one bounded test module using a dedicated test database, deterministic fixtures, and cached/pinned Docker images.
  5. Evaluate --pull behavior, Ctrl+C cancellation, and terminal-width output in CI before enabling broadly.
  6. Compare results and maintenance cost against Laravel-native assertions and RefreshDatabase.
  7. Decide to adopt via fork, retain for legacy only, or reject and rewrite tests.
  8. Document supported versions, Docker/image policy, ownership, and exit criteria before broad rollout.

Operational Impact

• Maintenance: v2.1.0 provides a maintenance signal that was previously absent, but release cadence remains low and the feature set still points to legacy PHP 7-era tooling. Any adoption implies dependency pinning, security scanning, and a planned exit path. Maintenance cost is likely moderate for a small shim and high for broad base-class compatibility or Docker image ownership.
• Support: Community support is likely sparse. Engineers will rely on source inspection, release notes, and internal documentation. v2.1.0 improves some local/CI ergonomics, but it does not establish a modern support model or Laravel-specific guidance.
• Scaling: Smaller default images and --pull can reduce stale-image friction, but parallel CI still requires careful database isolation and Docker image caching. --pull can add network latency and registry rate-limit exposure if used naively across parallel jobs. Large data sets, schema drift, and cross-engine differences still reduce scalability.
• Failure modes: Docker unavailable or misconfigured; registry auth/rate limits; mutable image drift if tags are not pinned; php-nightly instability; --pull network failures; PHPUnit/PHP fatal incompatibility; Laravel test-case conflicts; PDO driver variance; fixture ordering/type mismatches; test pollution from incomplete resets; schema drift after migrations; flaky CI due to shared databases; abandoned-dependency security findings. The Ctrl+C and $COLUMNS fixes reduce particular CI annoyances but do not address the core compatibility risks.
• Ramp-up: Low conceptual ramp-up for engineers familiar with PHPUnit, SQL, and Docker, but non-trivial compatibility and debugging effort due to old APIs and sparse documentation. Estimate a 1–2 day spike for a TPM-level go/no-go, plus additional time to validate Docker/image policy, then 1–2 weeks for a bounded wrapper/fork or test migration depending on suite size.