Behat Doctrine Fixtures Laravel Package

Technical Evaluation

Architecture fit — unchanged, still poor as stated. The package remains a Behat context that loads Doctrine ORM data fixtures into a database between scenarios. Laravel's default persistence is Eloquent, and Behat is not the Laravel test idiom (PHPUnit/Pest, with Dusk or Playwright for browser coverage). v2.2.0 does not touch this: it upgrades the Doctrine ORM dependency to 3.x and ships no Laravel/Eloquent surface, no new loaders, no isolation-semantics changes. The only supported shape is still Laravel + laravel-doctrine/orm + Behat — a rare intersection, consistent with 7 stars and 0 dependents.

What v2.2.0 changes. One substantive commit: Upgrade doctrine/orm to 3.* version (PR #26), plus a release commit (PR #27) whose title reads "Release 3.0" but which shipped as tag v2.2.0. Net effect on our evaluation:

• Question 1 (version compatibility) — partially answered. Doctrine ORM 3.x is now supported. That was previously "unverified"; it is now a stated target.
• New, offsetting risk introduced. The release notes say "upgrade … to 3.*" and say nothing about retaining ORM 2.x. If the constraint tightened to ^3.0, this is a silent breaking change delivered in a minor version bump — consumers on ORM 2.x get either an unresolvable dependency or, worse, a context that boots and behaves differently under DBAL 4 / ORM 3 semantics.
• Release hygiene is now a flagged concern. A PR titled "Release 3.0" landing as v2.2.0 is evidence that tags do not reliably encode compatibility. For a package we would pin, that is a trust signal, not a cosmetic detail.

Integration feasibility — unchanged in kind, marginally narrower in practice. Still technically feasible if Doctrine ORM is already a hard dependency: register the context in behat.yml, point it at the EntityManager, supply fixtures. The cost remains standing up Behat and Doctrine, in that order of justification. ORM 3.x adds a second-order cost: PHP 8.1+ floor, attribute-driven mapping (annotation driver removed), DBAL 4 underneath. If any existing fixture sets are annotation-based, they need conversion before this release is even loadable.

Technical risk.

• Adoption risk, high (unchanged): single-organization package, 7 stars, 0 dependents, no downstream validation.
• Maintenance cadence — slight positive revision: the June 2024 → present gap is broken, and there is a new external contributor (@serhiidonii). This is weak evidence of life, not of a support commitment; one drive-by contributor is not a patch pipeline.
• Version compatibility — narrowed but still unpinned. ORM 3.x now targeted; Behat 3.x, PHP 8.x, and ORM 2.x retention remain undocumented. No published CI matrix in the release notes.
• Breaking-change risk, new: ambiguous major/minor signalling means a composer update can move us across an ORM major without a major version number to warn us. Pin exactly; do not use caret ranges.
• Behavioral risk, unchanged: fixture load vs. purge semantics — truncate, transaction wrap, or both — and ordering guarantees remain a black box. The release does not address the area we care most about.
• Doctrine 3.x migration ripple: identity-map clearing, proxy generation, and lazy-loading behavior all shifted in ORM 3 / DBAL 4. This compounds the pre-existing "stale EntityManager across scenarios" failure mode rather than resolving it.
• Mixed-persistence risk, unchanged: Eloquent app + Doctrine fixtures means two mapping layers and schema drift.
• License: MIT — no legal or procurement friction.

Key questions (revised; struck-through items now answered).

1. Do we already run Behat, or would we be choosing it now? (unchanged — the decisive question)
2. Is Doctrine ORM a production dependency, or would it be introduced purely for tests? (unchanged)
3. Which ORM/Behat/PHP versions are supported? Partly answered: ORM 3.x targeted. Still open: is ORM 2.x still supported, what is the exact composer constraint, what is the PHP floor, and is there a CI matrix?
4. New: Was the ORM 3.x upgrade a hard cutover, and was v2.2.0 the intended tag for it? The PR title says 3.0.
5. Does the context purge, roll back transactions, or neither — and what are the isolation guarantees per scenario? (unchanged)
6. Does it support Alice/Nelmio loaders, or only raw Doctrine Data Fixtures? (unchanged)
7. Can it clear the EntityManager between scenarios under ORM 3.x, and is that behavior tested? (sharpened by the upgrade)
8. Can it boot without a Symfony kernel/container? (unchanged)
9. Is there any per-worker database isolation for parallel runs? (unchanged)
10. Who owns a fork if upstream goes quiet? (unchanged)

Reading the score. 0.525 with an opportunity signal of 30.87 remains low leverage, not broken. A Doctrine 3.x compatibility bump does not move the blast radius; it moves a package that was already outside our stack shape onto a newer version of a dependency we don't have.

Integration Approach

Stack fit — unchanged. Fits only Laravel + Doctrine + Behat. For a standard Eloquent Laravel application, fit is effectively zero, and v2.2.0 does not add Eloquent support.

Recommended path — do not adopt. Unchanged, and the v2.2.0 release strengthens the case rather than weakening it:

• Option A (default): stay on Laravel idioms — Pest/PHPUnit, RefreshDatabase, model factories, Dusk/Playwright for browser flows. Zero new dependencies, best support surface, lowest onboarding cost.
• Option B (if Gherkin is a hard business requirement): keep Behat but write a thin custom context (~100–200 LOC) over Eloquent and factories. Drops the Doctrine prerequisite entirely and gives us control over purge/transaction semantics — still the exact area where this package is a black box.

When this package is the right call. Still only when Doctrine ORM is already load-bearing in production and Behat is already the acceptance-test runner and the production ORM is already 3.x. That last clause is new: v2.2.0 makes this package a follower of the ORM 3 upgrade rather than a neutral observer, so adopting it now couples our test infrastructure to an ORM migration we may not otherwise have scheduled.

Migration path. Still greenfield selection, not data migration — the "migration" is test-infrastructure adoption. If converting from existing PHPUnit feature tests, introduce Behat in parallel on one bounded context (e.g. checkout) rather than converting the suite. If we were already on this package at v2.1.0, treat v2.2.0 as a major upgrade in disguise: read the composer diff before touching it, and do not let it ride in on a routine dependency sweep.

Compatibility — the step that changed most. Before any spike: read the composer.json constraint on doctrine/orm and doctrine/dbal in the v2.2.0 tag, confirm whether 2.x is retained or dropped, confirm the PHP floor, and confirm whether attribute-based mapping is now mandatory for fixture entities. Pin to an exact tag — the "Release 3.0 shipped as v2.2.0" mismatch means caret ranges are unsafe here.

Sequencing.

1. Confirm Behat + Doctrine are already present and already on ORM 3.x; if not, stop and take Option A or B.
2. Read the composer constraints and the ORM 3 diff on the tag; decide whether this is adoptable at all in our current lockfile.
3. Spike: one feature file, one fixture set, 2–3 scenarios; measure runtime and isolation behavior.
4. Test failure/rerun behavior, EntityManager clearing under ORM 3, and DB reset cost — the highest-probability source of pain, now compounded by the ORM upgrade.
5. Decision gate: adopt vs. thin custom context.
6. If adopted: pin the exact tag, document fixture conventions, add a dedicated CI job.

Effort estimate. 1–2 days for the spike. Add roughly half a day for the ORM 3 constraint audit that v2.2.0 now makes mandatory. Roughly one sprint to productionize either path. The custom Eloquent context still costs about the same as integrating and debugging this package, and leaves us with fewer dependencies.

Operational Impact

Maintenance. Primary concern, with one modest positive revision. There is now visible activity across a multi-month gap and a new external contributor, which is better than a dormant repo. But a single contributor fixing a single dependency bump is not a maintenance cadence, and the PR-title-versus-tag mismatch ("Release 3.0" → v2.2.0) tells us version numbers here are not trustworthy compatibility signals. Assume we own a fork if the maintainer stops. Mitigant: the codebase is small enough to read and fork in days.

Support. No vendor support, no Stack Overflow corpus, minimal issue history. Onboarding cost remains the composition of two niche skills — Behat contexts and Doctrine fixtures — not the package itself. Internal expertise is a prerequisite, not an outcome. Post-v2.2.0, add ORM 3 fixture conventions to that prerequisite list.

Scaling. Unchanged. Database-bound by design; fixture load per scenario does not parallelize without per-worker databases or a truncation strategy, so CI time grows roughly linearly in scenario count. The package does not solve sharding, parallelism, or suite partitioning. The ORM 3 bump neither helps nor hurts here.

Failure modes.

• New — silent ORM major crossing: a routine composer update pulls v2.2.0 and moves the test stack from ORM 2 to ORM 3 with no major version number to flag it. Mitigate by pinning the exact tag.
• New — ORM 3 / DBAL 4 behavior drift: changed identity-map, proxy, and lazy-loading semantics alter fixture-loading behavior in ways the package's happy-path tests may not cover.
• New — mapping-driver breakage: annotation-based fixture entities fail under ORM 3's attribute-only mapping; failure appears at context boot, not at review time.
• Dirty database state after a failed scenario, producing cascading false failures.
• Fixture reference collisions and ordering dependence between fixture sets.
• Stale EntityManager identity map across scenarios if the manager isn't cleared — sharper under ORM 3.
• Silent breakage on Behat version drift at context boot.
• Mixed Eloquent/Doctrine schema drift yielding "tests pass, production differs."
• Truncation-vs-transaction semantics colliding with MySQL implicit commits on DDL.

Ramp-up. Unchanged at the top: Gherkin is PM/BA-friendly and a genuine collaboration benefit. But authoring and debugging fixtures is engineering work in a Doctrine idiom most Laravel developers don't hold, and v2.2.0 raises the floor slightly by requiring ORM 3 familiarity. Expect 2–4 weeks to fluency, and only if Doctrine is already familiar to the team.

Bottom line. v2.2.0 is a Doctrine ORM 3.x compatibility bump packaged as a minor release, with a tag that disagrees with its own PR title. It answers one open question, introduces a breaking-change and release-hygiene risk, and leaves the two reasons we declined — Behat as the runner, Doctrine as the persistence layer — entirely untouched. Recommend not adopting; if Gherkin is a hard requirement, build a thin Eloquent-native context instead, and revisit this package only if Doctrine becomes a production commitment on 3.x.