- Is gorghoa/scenariostate-behat-extension a Laravel package?
- No. It is a Behat extension that registers a ScenarioState service into Behat's own service container and exposes it to step-definition contexts through a constructor argument resolver. It has no relationship to Laravel's container, Eloquent, HTTP kernel, or Artisan. The only integration surface is behat.yml plus the Composer autoloader.
- How do I install gorghoa/scenariostate-behat-extension?
- Install it with Composer alongside Behat, then enable the extension in your behat.yml. Behat's Symfony-based extension system discovers it through that registration and wires the state service automatically. There are no Laravel service providers, config files, or publish steps involved.
- How do I configure ScenarioState in behat.yml?
- Configuration is limited to registering the extension in the extensions section of behat.yml. That file, plus the Composer autoloader, is the entire integration surface described by the package. There are no documented Laravel-style config files or environment variables to manage.
- Does this extension work with PHPUnit, Pest, or a Laravel test suite?
- No. It only works inside Behat, and its fit with a PHPUnit or Pest-first Laravel team is effectively zero. If your suite is built on Laravel's default testing stack, this package adds nothing because there are no Behat step definitions to inject state into. It only makes sense for teams already running a Behat acceptance layer with multiple contexts handing data off to each other.
- How do I share data between Behat step definitions without static properties?
- You inject the ScenarioState object into your context constructor and use it as a shared bag for arbitrary values. Every step definition in that context can read and write the same object instead of passing data through globals or coupling contexts together. This keeps step classes readable and avoids fragile hand-off patterns between contexts.
- Is ScenarioState reset automatically for every scenario?
- Yes. The extension enforces automatic isolation so state is cleared between scenarios, typically via a BeforeScenario reset hook in the container wiring. That prevents data from one scenario leaking into the next, which is the main failure mode of static property or singleton-based sharing. You get a fresh container per scenario without writing teardown code yourself.
- Which Behat and PHP versions does version 1.0.7 support?
- Version 1.0.7 is a patch release whose only noted change is widening Symfony 5 component constraints, which matters because Behat is built on Symfony DI, Console, EventDispatcher, Translation, and Yaml components. The release notes state no PHP 8 support, no change to the Behat version envelope, and include no CI matrix evidence. Run a real Composer resolution against your pinned Behat and PHP versions before assuming compatibility, since a widened constraint can permit combinations nobody has tested.
- Is gorghoa/scenariostate-behat-extension actively maintained?
- It is best described as low-activity and sporadically maintained, with demonstrated receptiveness to external pull requests. A single community-contributed constraint fix landed after a multi-year gap, which is better than an abandoned project but is not a maintenance commitment. There is no published support window, no security process, and no release cadence, so treat upgrades as your responsibility.
- What are the alternatives to using this package for Behat scenario state?
- The functionality is roughly 50 to 100 lines: a container service, a BeforeScenario reset hook, and a constructor argument resolver. Writing that yourself eliminates the entire compatibility, support, and upgrade obligation while giving you full control over PHP and Behat version drift. The package remains the faster option if your team already runs Behat and just needs the wiring done for you.
- What are the downsides of a shared mutable state bag in acceptance tests?
- A shared mutable container makes step ordering implicit, because steps silently depend on state written by earlier steps. When a scenario fails, you have to trace which step mutated the bag rather than reading explicit inputs and outputs. The package solves the globals problem but not the coupling problem, so adopting it should be a deliberate team decision backed by conventions for who writes which keys.