Behat Doctrine Fixtures Laravel Package

Product Decisions This Supports

• Whether to adopt BDD (Behat) at all in a Doctrine-backed PHP codebase. This package is the difference between "Behat is viable for our acceptance suite" and "we'd have to build scenario-level fixture isolation ourselves." It directly informs the buy-vs-build call for test-data plumbing: a small MIT context that loads Doctrine data fixtures between scenarios is table stakes for a readable, deterministic Gherkin suite.
• Test-data strategy for acceptance tests. Choosing between per-scenario fixture loading, transaction rollback, and database truncation is a real architectural decision with downstream cost. This package commits you to the Doctrine DataFixtures loader model — which is good if your fixtures already live there, and a constraint if you're standardized on Laravel factories or seeders.
• Doctrine ORM version strategy, now coupled to acceptance testing. As of v2.2.0 the package requires doctrine/orm 3.x. Adopting it is no longer a standalone test-tooling decision — it implicitly ratifies (or forces) an ORM 2→3 migration, and conversely, any team still on ORM 2.x is pinned to v2.1.0 or a fork. Worth naming explicitly in the roadmap rather than discovering it at install time.
• Standardizing QA/engineering collaboration. Named fixture sets behind Gherkin steps lower the barrier for QA and product to write and read scenarios without touching PHP. That's a hiring, onboarding, and role-boundary decision as much as a technical one.
• Roadmap gating for "quality infrastructure" work. If acceptance testing is on the roadmap, this is a cheap enabler; if it isn't, this package has no standalone value. It should be evaluated as an ingredient, not a product.
• Vendor-vs-depend decision for internal tooling. Still a low-adoption, single-org-origin repository (MacPaw). The v2.2.0 release adds a second contributor and a major-dependency bump, but no community growth signal. The realistic decision remains "vendor or fork a small context class" rather than "take a dependency" — that is a supply-chain and maintenance-ownership decision worth making explicitly.

When to Consider This Package

Consider it when all of the following hold:

• You are already running Behat (or are committed to it) and your persistence layer is Doctrine ORM 3.x — typically Symfony, or a Doctrine-integrated non-Laravel app. If you are on ORM 2.x, v2.2.0 is not installable for you; pin v2.1.0 or vendor.
• Your fixtures are already authored as doctrine/data-fixtures classes, and you want them loaded/isolated per scenario without writing a custom context.
• You need deterministic, isolated scenario data and are willing to own the code: expect to fork, pin, or vendor.
• Your PHP/runtime is compatible with the ORM 3 requirement (which drags in its own PHP and doctrine/dbal floors), and a low-traffic, single-org repository is acceptable for test-only code (blast radius is limited to CI).

Look elsewhere when:

• You're on Laravel. Laravel's grain is Pest/PHPUnit with RefreshDatabase, model factories, and seeders. Behat is uncommon, and this package adds a Doctrine dependency you almost certainly don't want in a Laravel app. behat/laravel-style extensions or plain Pest feature tests are the idiomatic path.
• You are on Doctrine ORM 2.x and are not planning the ORM 3 migration this cycle. This release narrows the compatibility window rather than widening it; it is not a reason to accelerate an ORM upgrade on its own.
• You need parallel test execution, per-test database isolation, or high test throughput — the fixture-reload model is slow and this package offers no parallelism story.
• You want an actively maintained dependency with community support, security responsiveness, and a predictable release cadence. Adoption remains tiny, and the v2.2.0 packaging is a caution flag: the PR is titled "Release 3.0" but ships as v2.2.0 while containing a breaking dependency bump — versioning and release hygiene are not yet reliable signals.
• Your data setup is better expressed as factories/builders than as static fixture classes; fixture-loading contexts tend to calcify test data over time.
• You need production-grade guarantees. This is test scaffolding; it should never influence runtime architecture choices.

How to Pitch It (Stakeholders)

For executives: This is a small, free, MIT-licensed helper that lets our acceptance tests (the plain-English specs QA and product can read) load consistent test data automatically. It doesn't ship to customers and can't affect production. The newest release is a maintenance bump that moves it onto Doctrine ORM 3 — meaning it only works if we're already on, or moving to, that version; it isn't a feature we'd adopt on its own. The real cost isn't the license, it's ownership: adoption is still negligible and the release is mislabeled (a "3.0" PR shipped as 2.2.0), so our engineers would maintain it. Recommendation: treat it as a reference implementation to fork or copy, not a dependency to lean on, and only pursue it if BDD acceptance testing is already on the roadmap and ORM 3 is our direction.

For engineering: It's a Behat context that wires Doctrine data fixtures into scenario setup. v2.2.0 upgrades doctrine/orm to 3.x — a breaking change in practice even though it shipped as a minor, so treat the version constraint as hard: ORM 2.x users stay on v2.1.0 or vendor. If we're on Symfony/Doctrine 3 and already writing doctrine/data-fixtures classes, this saves a day or two of context-writing. If we're on Laravel, it's a mismatch — our factories plus RefreshDatabase are the better answer, and adopting Doctrine fixtures would fight the framework. Either way, budget for vendoring it: pin the commit, read the whole thing (it's small), and add it to our internal test-tooling ownership list. Note the release also adds a second contributor, which marginally improves bus factor but doesn't change the underlying assessment.