Crucible Laravel Package

Product Decisions This Supports

• Test modernization and migration risk: v1.1.7 deepens Pest behavioral parity in the areas most likely to silently corrupt a migration: scoped hooks inside describe(), beforeAll/afterAll handling, global afterEach ordering from Pest.php, and ->in(__DIR__) directory selection. This directly supports decisions about whether to standardize on Pest-compatible tooling or migrate suites with lower risk — parity gaps in hook scoping and directory targeting are exactly the failure modes that produce false confidence during a migration.
• Quality-gate investment: Cumulative fixes across v1.1.5–v1.1.7 (mutation resume correctness, impact selection, mutant generation, pcov coverage crashes, and now Pest hook/suite-composition semantics) reduce the risk of unreliable quality signals. Deciding to fund stronger CI gates is safer when coverage and mutation results are trustworthy and suite composition matches the reference runner.
• Build vs. buy for test infrastructure: The case for adopt-or-pilot over bespoke tooling strengthens. Replicating Pest's hook scoping, global-hook ordering, and path-based suite selection in-house is subtle, easily wrong, and often fails silently — v1.1.7 documents exactly that class of bug (->in(__DIR__) matching nothing and dropping classes, traits, groups, and hooks without error).
• Roadmap prioritization for developer productivity: Use compat-check results, mutation scores, coverage reliability, and PHPStan/Pest friction to prioritize test-debt work, CI stabilization, and framework-upgrade readiness. The v1.1.7 fixes convert several previously silent misconfigurations into either correct behavior or explicit collection-time refusal, which makes audit findings actionable.
• Use cases: Laravel test-suite modernization, Pest/PHPUnit upgrade validation, validating Pest.php suite configuration and describe() hook semantics, CI coverage hardening, mutation-score tracking, architecture-rule adoption, and pre-migration compatibility checks in monorepos or multi-package Laravel estates.

When to Consider This Package

Consider adoption when:

• The team uses Laravel, Pest, and/or PHPUnit, especially with pestphp/pest-plugin-laravel.
• You rely on describe() blocks, scoped beforeEach/afterEach, beforeAll/afterAll, or Pest.php global hooks — v1.1.7 aligns these with Pest's ordering and scoping rules and rejects unsupported beforeAll/afterAll inside describe() at collection time rather than running them incorrectly.
• Your Pest.php uses ->in(...) path targeting for per-directory classes, traits, groups, or hooks; the prior silent-drop behavior is a real configuration hazard worth verifying.
• You need to validate compatibility between a Crucible/Pest-style dialect and an existing Pest/PHPUnit oracle before changing test infrastructure.
• You want mutation testing, coverage, and compatibility checks in CI without building custom tooling.
• You use PHPStan with Pest-style hooks and need typed properties such as $this->user assigned in beforeEach.
• You are willing to pilot an actively evolving developer tool and validate results against your current test runner.
• You value concrete fixes for CI blockers such as pcov coverage signal 11 failures, incorrect toThrow() behavior, stale verdicts on resumed mutation runs, and mis-scoped or silently dropped hooks.

Look elsewhere when:

• You need production runtime features; this is developer/CI tooling, not application functionality.
• You require a mature, long-supported vendor product with SLA-backed compatibility guarantees and minimal tolerance for evolving behavior.
• Your stack is not Laravel/PHP or does not use Pest/PHPUnit.
• You only need a simple test runner and mutation testing or compatibility-oracle checks would be overkill.
• You cannot pilot before broad rollout. Two consecutive patch releases fixed behavioral parity and silent-configuration issues, which indicates continued validation against real projects is still important.

How to Pitch It (Stakeholders)

Executive summary: This is an engineering-enablement package that reduces risk and cost in Laravel/PHP test modernization. v1.1.7 closes behavioral gaps with Pest in suite composition and hook execution — areas where mistakes cause tests to run in the wrong scope or not at all, without any error. Combined with the v1.1.5 reliability work on mutation testing, coverage, and PHPStan, this improves release confidence and lowers CI/test-infrastructure waste. It is not customer-facing.

Engineering summary: v1.1.7 is a Pest-parity correctness release with no breaking changes called out. It fixes beforeEach/afterEach inside describe() running for every test in the file (now scoped to its block and nested blocks, in declaration order with file hooks); rejects beforeAll/afterAll inside describe() at collection with Pest's message and runs nothing from that file; orders a global afterEach from Pest.php before the file's own hooks; and fixes ->in(__DIR__) matching nothing, which had been silently dropping classes, traits, groups, and hooks. Teams with Pest.php path targeting should audit those blocks, since the previous behavior failed silently. Re-run coverage and mutation baselines after upgrade.

Recommended ask: Pilot in one Laravel repository and one CI lane. Track compat-check pass rate, mutation-score trend, coverage stability, PHPStan noise, and verified Pest.php suite selection. Use a two-sprint decision gate before broader adoption.