Behat Orm Context Laravel Package

Product Decisions This Supports

• Test-infrastructure build vs. buy. Whether to adopt a maintained OSS Behat context bundle for Doctrine ORM instead of writing and owning your own step definitions, transformers, and hooks. Every context you don't maintain is sprint capacity returned to the roadmap. The v2.0.0 release widens the supported matrix without changing the public API, so this remains a "buy a small, forkable asset" call rather than a platform commitment.
• BDD investment sizing. Whether to fund a Behat layer at all for Doctrine-backed acceptance tests (fixture loading, entity assertions, database state checks), and how much of it can be covered by off-the-shelf contexts. v2.0.0 keeps the surface area stable — it is a compatibility release, not a feature expansion — so it does not change the scope of what you'd still have to build yourself.
• Acceptance-test coverage for persistence code. Lets the team express "given these entities exist, when this operation runs, then the database holds X" in Gherkin — useful for repository, entity-mapping, and migration-adjacent behaviours that unit tests with a mocked EntityManager won't catch end-to-end.
• Framework-version roadmap alignment. The v2.0.0 constraint widening (Symfony 6.4–8, Doctrine ORM 2–3, DBAL 2–4) materially changes the useful-life calculus: the package is no longer pinned to a single Symfony minor line. If your roadmap includes a Symfony 7 or 8 upgrade, or a Doctrine ORM 3 migration, this dependency no longer becomes a blocker at that boundary — that is a genuine de-risking of the "adopt it now, regret it at the next major upgrade" path.
• Dependency-risk budgeting. A concrete input to your "unmaintained/obscure dev dependency" policy: still low-adoption and effectively single-maintainer, but MIT-licensed, isolated to require-dev, easy to fork, and now demonstrably maintained across a framework major. A v2.0.0 that only widens constraints and explicitly keeps the public API unchanged is a good maintenance signal — it suggests the maintainer is tracking upstream rather than letting the package rot. That is still a "vendor and pin" decision, not a "block" decision.
• Stack-standardisation calls. It surfaces the real question: this is a Symfony bundle. If the product is Laravel/Eloquent, adopting it remains a non-starter and the roadmap decision is "use Laravel's native Pest/PHPUnit and Behat tooling instead." v2.0.0 does not change that — supporting Symfony 7 and 8 does not create Eloquent value.

When to Consider This Package

Adopt when all of these hold:

• The application is Symfony 6.4–8.x and PHP 8.1+ (Symfony 6.4 LTS is the floor; anything on Symfony <6.4 is now explicitly out).
• The product uses Doctrine ORM for persistence — v2.0.0 supports both ORM 2 and ORM 3 and DBAL 2 and 4, including version-specific JSON field handling, so an in-flight ORM 3 / DBAL 4 migration is no longer a reason to defer.
• You are already committed to Behat 3 as your acceptance-test runner — this is an accelerant, not a reason to adopt BDD.
• You want ORM step definitions as a dev-only dependency with no runtime footprint. Its own suite runs against a mocked EntityManager, so no services or databases are required to build or test it.

Look elsewhere — or plan to fork — when:

• You are on Laravel/Eloquent: still no meaningful value; the ORM abstraction is Doctrine-specific.
• You are on Symfony <6.4 or PHP below 8.1: v2.0.0 drops you; either stay pinned to v1.2.0 (and accept an unmaintained branch) or upgrade the platform first.
• Your policy requires community-scale adoption, multiple maintainers, or a support contract. Nothing in this release changes the adoption profile. Treat it as internal code you happen to source externally: vendor it, pin the version, and assume you own the upgrade path.
• Your own CI is pinned to older dev tooling and you intend to fork and run the package's own checks: v2.0.0 raises the internal floor to PHPUnit 10.5/11, PHPStan 2 + phpstan-doctrine 2, Rector 1/2, PHPCS 4, and Slevomat 8. This is inert at install time (a dependency's require-dev isn't installed by Composer), but it is real work if you fork and maintain.
• You need production/runtime ORM helper behaviour — this is test tooling only.
• You need migration/seed orchestration beyond Behat contexts — pair it with dedicated fixture tooling rather than stretching this bundle.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed developer-tooling dependency that reduces the hand-written test plumbing our engineers maintain for database-layer acceptance tests. It carries zero production runtime footprint — it is installed as a dev dependency and never ships to customers. The trade-off is provenance: it is a low-adoption, effectively single-maintainer package, so we mitigate by pinning the version inside our own repository rather than relying on the upstream project's longevity. The v2.0.0 release is good news on that risk: the maintainer widened support to Symfony 6.4 through 8 and Doctrine ORM 2 and 3 without changing the public API, which means the dependency should survive our next framework and ORM upgrades instead of forcing a rewrite at exactly the wrong moment. No new budget or headcount is implied — this is a maintenance release, and the recommendation is to bump and pin.

To engineering: A Symfony bundle supplying Behat contexts for Doctrine ORM — step definitions and hooks for entity/fixture setup and assertions, so teams write Gherkin instead of maintaining bespoke contexts. v2.0.0 is a constraint-widening release with an explicitly unchanged public API: Symfony 6.4–8, Doctrine ORM 2–3, DBAL 2–4 (with version-aware JSON field handling), Behat 3, PHP ^8.1. The only breaking change is the Symfony <6.4 / PHP <8.1 floor, both already EOL — so an upgrade from v1.2.0 should be a composer update plus a regression run, not a migration. Internal quality signalling remains strong: PHPStan max level now on 2.0 with phpstan-doctrine, PSR-12/Slevomat, Rector, PHPUnit, all behind a single composer dev-checks entrypoint; the dev-tooling floors (PHPUnit 10.5/11, PHPCS 4, Rector 1/2, Slevomat 8) only bind if you fork and run its own suite. Recommend adopting as a require-dev dependency, pinning the version, and treating it as a forkable internal asset rather than an upstream we depend on.