Test Laravel Package

Technical Evaluation

Architecture fit. hoa/test is not a library you integrate into an application; it is a self-contained test framework with its own runner (hoa test:run), its own assertion vocabulary, and its own test-suite orchestration model. It exposes no Laravel service provider, facade, config file, or artisan command, and it has no PHPUnit bridge. It occupies the same architectural slot as PHPUnit/Pest — meaning it competes with, rather than complements, Laravel's native testing stack. For a Laravel codebase there is effectively no runtime surface and no test-time fit unless the goal is specifically to execute tests written in Hoa's DSL.

Integration feasibility. Installable as require-dev, but it drags in a parallel utility universe of roughly a dozen hoa/* packages (consistency, stream, protocol, iterator, file, regex, math, zformat, ustring, and transitive peers). None of that code is shared with Laravel, Symfony, or PSR interfaces. Practically: no JUnit XML output, no coverage driver integration, no PhpStorm/VS Code runner support, no php artisan test compatibility, and no way to express Laravel-specific testing concerns (RefreshDatabase, Http::fake, Bus::fake, actingAs). CI would require a second, separate test invocation with a second reporting path.

Technical risk. High, and asymmetric. The repository is archived, last released 2017-08-18, with 11 stars and 0 dependents — there is no maintainer, no CVE response process, and no community knowledge base. The declared php constraint targets the 5.5–7.x era, so on PHP 8.1+ there is a strong likelihood of fatal errors from removed functions, dynamic-property deprecations, and reflection signature changes. Abandoned transitive dependencies create Composer 2 resolution conflicts and will trip composer audit / abandoned-package gates in most modern pipelines. The one mitigating factor is scope: it is dev-only, so a breakage cannot take down production — it can only take down CI.

Key questions.

1. Does any code in the estate actually contain Hoa-style tests, or is this a greenfield evaluation? (If greenfield, the answer is no.)
2. Is the objective "test our Laravel app" or "run the Hoa libraries' own suites" — the latter is the only defensible use case and even then only in a quarantined job.
3. What is the minimum supported PHP version, and does the build matrix include 8.1+?
4. Does the organization already have an abandoned-dependency policy with an allowlist? If not, this package should force one.
5. If legacy tests must be preserved, is a maintained internal fork staffed and budgeted, or is conversion to PHPUnit cheaper?

Integration Approach

Stack fit. Treat it as test-time-only and, for a Laravel 10/11 (PHP 8.1+) target, as a non-fit. The idiomatic replacement is PHPUnit 10/11 plus Pest 2/3, Illuminate\Foundation\Testing for HTTP/database/queue fakes, and Collision for ergonomic CLI output. Nothing in hoa/test fills a gap that stack leaves open.

Migration path.

1. Inventory — grep for Hoa\Test, hoa test:run, vendor/bin/hoa, and any test files that do not follow PHPUnit's *Test.php naming convention. Establish how many assertions and suites are genuinely in play; Hoa suites are often small.
2. Freeze — prohibit new Hoa-style tests immediately; require PHPUnit/Pest for all new work.
3. Quarantine — if legacy tests exist, move them into a separate Composer project (tools/legacy-tests) pinned to a PHP 7.4 CI image, so the abandoned dependency graph never enters the application's composer.lock.
4. Transcode — the assertion surface maps cleanly (assertSame, assertTrue, assertInstanceOf, exception expectations become expectException). Hoa's suite/operation constructs become PHPUnit test classes plus data providers.
5. Parity gate — run legacy and converted suites in parallel for one full cycle; require identical pass/fail sets before deleting the legacy job.
6. Removal — drop hoa/test and all transitive hoa/* entries; verify with a clean composer install and an audit run.

Compatibility. There is no forward-compatibility path. Backward compatibility exists only inside a container pinned to the PHP version the tests were written against. Do not attempt to patch the package in place inside the application's dependency tree.

Sequencing. Audit (≈1 sprint) → quarantine and split the dependency graph (≈1 sprint) → convert highest-value suites first, prioritizing anything covering payment, auth, or data integrity (1–3 sprints depending on volume) → delete. The ordering matters: quarantine before conversion, otherwise a routine composer update can break CI mid-migration and stall the whole effort.

Operational Impact

Maintenance. Zero upstream maintenance is available. Any bug, PHP compatibility break, or security finding becomes an internal fork-and-own obligation. For a dev-only test tool, that is almost never a rational use of engineering time relative to rewriting a handful of assertions.

Support. No vendor, no maintainer, no issue tracker activity, 11 stars and 0 dependents, and effectively no Stack Overflow or blog surface. Support degrades to reading archived source. This creates a single-person knowledge dependency inside the team and a real bus-factor risk for any suite left in place.

Scaling. The custom runner is effectively single-process with no parallelization, no sharding, and no machine-readable output. Test suite growth therefore increases CI wall-clock linearly, and there is no path to the reporting most teams depend on — no JUnit ingestion, no trend dashboards, no per-test flake attribution, no coverage merging. Writing an adapter to emit JUnit XML is possible but is bespoke work with no reuse.

Failure modes.

• A PHP minor upgrade lands and the runner fatals on boot — CI stops with an opaque error and no upstream fix.
• A composer update resolves conflicting hoa/* version constraints and blocks all other dependency work.
• The abandoned-package/audit gate starts failing and forces either an exception or an emergency migration.
• Silent non-discovery: tests that do not match the runner's conventions simply never execute, producing false confidence and coverage blind spots with no warning.
• Coverage gaps go undetected because no coverage driver integration exists, so quality gates cannot be enforced on that portion of the suite.
• Onboarding engineers write PHPUnit tests by default, and the Hoa suite slowly rots into an unread, unrun artifact that still costs CI minutes.

Ramp-up. Every engineer already knows PHPUnit or Pest; the marginal ramp is zero. Hoa's DSL requires roughly a week per engineer to reach competence, with no documentation beyond archived source, and that investment is non-transferable. Recommend capping total investment at the conversion cost and treating the package as a removal task, not an adoption decision.