Technical Evaluation

Architecture fit

This is a Behat/Sulu content-context extension, not application runtime code. It sits in the test automation layer and provides Gherkin steps for Page, Article, and Snippet fixtures.
Strong fit for teams testing Sulu-based content applications; low intrusion into production architecture.
Poor fit if the “Laravel/PHP” stack is actually Laravel-first without Sulu. v2.0.0 explicitly drops Sulu 2 support, so the package is now tightly coupled to Sulu 3 and Symfony/Behat tooling.
The reworked contexts are described as “not feature-complete,” meaning architectural coverage is directionally correct but not guaranteed complete.

Integration feasibility

Composer-based integration is straightforward, but v2.0.0 is a coordinated upgrade: Sulu 3 is required, and elbformat/symfony-behat-bundle:^1.6 becomes a required transitive dependency.
Feature-file migration is required because the step Given there is a(n) (:template) page as child of :parentId is removed in favor of _parentId or _parentSlug rows.
Feasible for teams already on Sulu 3 and Behat; not feasible as a drop-in for Sulu 2 projects without a larger CMS upgrade.

Technical risk

High BC risk: Dropping Sulu 2 blocks adoption for any team still on Sulu 2.
Medium BC risk: Removed Gherkin step will break existing feature files; failures are explicit, which is good, but migration effort must be scoped.
Medium risk: New argument-fetching layer (tables, YAML, JSON) via symfony-behat-bundle ^1.6 changes fixture behavior and adds a dependency to govern.
Medium risk: “Not feature-complete” contexts may cause coverage gaps for Article/Snippet scenarios or edge-case Page structures.
Low/positive risk: Improved _webspaceKey and locale support reduces risk for multi-site and multi-locale test suites; GitHub Actions matrix builds improve release confidence.

Key questions

Are we on Sulu 2 or Sulu 3 today? If Sulu 2, v2.0.0 is not adoptable until the CMS upgrade completes.
Is this actually a Sulu/Symfony stack, or a Laravel application? If Laravel-only, architecture fit is low and the package should not be adopted.
How many feature files use the removed as child of :parentId step, and can we codemod or search-replace them?
Which contexts do we depend on: Page only, or Article and Snippet as well? “Not feature-complete” needs validation against our scenario inventory.
Do we need YAML/JSON argument fixtures, or are Gherkin tables sufficient? This affects whether the new symfony-behat-bundle dependency is worth the upgrade.
What PHP/Behat/Symfony versions are covered by the new matrix builds, and do they match our CI image?

Integration Approach

Stack fit

Fits PHP/Composer projects running Behat against Sulu 3 with Symfony. It is not a Laravel-native package and should be treated as Sulu test tooling.
If the organization has a mixed portfolio, adopt only for Sulu 3 content teams; do not standardize it across Laravel-only services.

Migration path

Two-phase upgrade: first move the application to Sulu 3, then upgrade this package to ^2.0.
Teams staying on Sulu 2 should pin to the 1.x line and defer v2.0.0.
Update feature files by replacing the removed child-page step with explicit _parentId or _parentSlug rows, and adjust url values to match the new parent/child structure.
Inventory existing Gherkin fixtures before upgrading; treat this as a test-code migration, not just a dependency bump.

Compatibility

Sulu 3 only. Confirm Behat, Symfony, and PHP versions against the new GitHub Actions matrix (PHP versions, with/without Form bundle).
Verify elbformat/symfony-behat-bundle:^1.6 compatibility with the existing Behat/Symfony versions.
Validate whether Article and Snippet contexts meet current scenario coverage before relying on them.

Sequencing

Confirm Sulu 3 readiness and current package version usage.
Inventory feature files using the removed step and any Article/Snippet scenarios.
Upgrade dependency in a branch and resolve symfony-behat-bundle compatibility.
Migrate Gherkin fixtures (_parentId / _parentSlug).
Run the full Behat suite; identify gaps from “not feature-complete” contexts.
Add local context extensions or workarounds for uncovered scenarios.
Roll out to CI and document the new fixture patterns.

Maintenance

Adds ongoing tracking for elbformat/symfony-behat-bundle and Sulu 3 compatibility.
“Not feature-complete” contexts may require local extensions, custom steps, or temporary skips, increasing maintenance burden on QA/test engineering.
Pin versions carefully; v2.0.0 is a major release with explicit BC breaks.

Support

Open-source/community support with an upgrade cadence tied to Sulu releases. No vendor SLA assumed.
Internal ownership should sit with QA automation or platform engineering, not individual product teams.
Document migration patterns for _parentId / _parentSlug and new _webspaceKey / locale usage.

Scaling

Test-only package, so no production runtime scaling impact.
Improved argument fetching via tables/YAML/JSON can improve fixture reuse and multi-locale test scalability.
Better webspace and locale support helps scale test coverage across multi-site Sulu installations.
CI matrix builds improve predictability across PHP versions and Form bundle configurations.

Failure modes

Hard failure: feature files using the removed child-page step will fail until migrated.
Adoption blocker: Sulu 2 projects cannot use v2.0.0 at all.
Silent coverage gap: “not feature-complete” contexts may lack steps for certain Article/Snippet or Page scenarios, leading to skipped or manually implemented coverage.
Dependency mismatch: symfony-behat-bundle ^1.6 or Sulu 3 incompatibility with existing Behat/Symfony versions.
Fixture drift: changed argument resolution may alter how YAML/JSON/tabular data is interpreted.

Ramp-up

Moderate. Teams need Behat/Gherkin familiarity plus Sulu content-structure knowledge (pages, articles, snippets, webspace keys, locales).
The new _parentSlug / _parentId patterns and YAML/JSON fixture options require documentation and examples.
Plan a short enablement session for QA and developers before broad rollout.