Atoum Bundle Laravel Package

Product Decisions This Supports

• Test tooling standardization (build vs. buy vs. reuse): Informs whether engineering standardizes on atoum (via this bundle) or on the de facto PHPUnit/Pest ecosystem. This is a reuse decision, not a build decision — but it locks in a testing DSL, CI integration, and developer onboarding path for years.
• Platform upgrade sequencing: v5.0.0 requires Symfony 7.4/8.0+ and PHP 8.2+. Adopting it is effectively a commitment to a platform baseline, so it belongs in the same roadmap conversation as the Symfony/PHP upgrade — not as an isolated dev-tooling ticket.
• Supply-chain and maintainer-risk posture: This is the first release under a new vendor name (atoum-next/atoum-bundle) built on a forked core (atoum-next/atoum ^5.0). That is a governance signal worth a deliberate accept/mitigate decision, especially for teams with dependency-review or SBOM policies.
• Quality-gate investment: Determines whether test-infrastructure budget goes toward atoum-specific tooling (bundle config, CI wiring, migration of existing suites) versus consolidating on the more widely supported alternative.
• Not a product-feature dependency. This bundle ships no runtime capability to customers. It should never appear on a customer-facing roadmap; it belongs in engineering-enablement and technical-debt planning.

When to Consider This Package

Adopt when all of the following hold:

• The stack is Symfony 7.4 or 8.0+ on PHP 8.2+ — this is a Symfony bundle, not a Laravel package; it offers nothing to a Laravel codebase.
• The team already uses atoum, or has a specific, articulable reason to prefer its assertion model over PHPUnit/Pest.
• You accept the maintenance trajectory of a fork under new maintainership. Confirm the release cadence, issue triage, and security-response expectations of atoum-next before committing.
• You have budgeted the v5.0.0 migration as a major-version upgrade with breaking changes — read CHANGELOG.md fully; the namespace/vendor move and the atoum ^5.0 core bump will not be a drop-in.

Look elsewhere when:

• The stack is Laravel or framework-agnostic — use PHPUnit/Pest, which this package does not serve.
• You need vendor-backed support, a large hiring pool, or the broadest plugin/extension ecosystem.
• You are pinned below Symfony 7.4 or PHP 8.2 — v5.0.0 is unusable and no upgrade path is offered here.
• Dependency-governance policy disallows recently-forked or single-maintainer packages without an internal mitigation plan.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a testing-tooling update, not a product feature. It has no direct customer impact and no revenue line attached. Its relevance is indirect: it affects how quickly engineering can validate changes and how much upgrade work is queued. The v5.0.0 release is a major version under a new project name, requires a modern Symfony/PHP baseline, and carries breaking changes — so the real decision is whether we want to keep investing in atoum as our test framework or consolidate on the more widely adopted PHPUnit. Recommendation: treat this as a small, contained engineering-enablement decision with an explicit maintainer-risk check, not a roadmap item.

For engineering: v5.0.0 is the first release as atoum-next/atoum-bundle, rebased on atoum-next/atoum ^5.0, targeting Symfony 7.4/8.0+ and PHP 8.2+. Expect breaking changes — read CHANGELOG.md before touching CI. Two things to validate before we commit: (1) does the atoum-next fork have a credible maintenance and security-response cadence, and (2) is the migration cost lower than the cost of porting our suites to PHPUnit. If either answer is unfavorable, the cheaper path is consolidation, not migration.