- How do I install friends-of-behat/symfony-extension?
- Install it as a dev dependency with composer require --dev friends-of-behat/symfony-extension. It is a test-only package, so it belongs in require-dev alongside Behat itself and never in your production dependency set. After installing, enable the extension in your behat.yml and register your test services, typically in a dedicated services_test.yaml or tests/ configuration file. No production code changes are required.
- Which Symfony and PHP versions does this extension support?
- The README advertises Symfony ^6.0 and ^7.0, but the v2.7.0 changelog drops PHP below 8.3 and Symfony below 7.4, so the documentation and the real constraints can drift apart. Always read the composer.json constraint of the exact tag you install and pin that version explicitly rather than relying on the README. Version majors track Symfony majors, so check that a compatible tag exists for the Symfony and PHP pair already in your lockfile before planning a Behat suite.
- How do I define Behat contexts as Symfony services?
- Instead of letting Behat construct contexts itself, you register them as services in your test service container, and the extension resolves them through Symfony's dependency injection container with autowiring and autoconfiguration enabled. That means a context can constructor-inject a repository, an HTTP client, a clock, or a message bus probe with no hand-written glue code. Contexts stay idiomatic Symfony services rather than a parallel universe of static accessors, which is the main architectural reason to adopt this bridge.
- How does the Mink driver test a Symfony application without a server?
- The built-in Mink driver is backed by BrowserKit and dispatches requests straight into the Symfony Kernel instead of over the network. You get the full request and response cycle, including routing, middleware, and serialization, with no web server, port allocation, or nginx vhost configuration. What you do not get is TLS, real HTTP transport semantics, JavaScript execution, or async behaviour, so treat it as the fast path rather than a full browser replacement.
- What does the behat.yml configuration for SymfonyExtension look like?
- You enable the extension in behat.yml and point it at your application Kernel, setting the kernel path, the environment, and the debug flag. You also register the test service configuration that declares your contexts as services, usually through a services_test.yaml file or a tests/ directory. The extension documentation includes a full configuration reference, so start there and keep the environment aligned with the one your CI boots.
- What is the difference between SymfonyExtension and behat/symfony2extension?
- behat/symfony2extension is the older, deprecated integration, while this package is its modern replacement aimed at Symfony 6 and 7. The key difference is that contexts are proper Symfony services with autowiring and autoconfiguration, rather than objects Behat instantiates and wires itself. It also ships a Kernel-backed Mink driver so scenarios run in-process without an HTTP server, and it integrates with FriendsOfBehat/PageObjectExtension if your team already uses page objects.
- Can I use this driver for JavaScript or cross-browser testing?
- No. The in-process BrowserKit driver cannot execute JavaScript, handle real TLS, or emulate a full browser, so cross-browser and JS-heavy scenarios are out of scope. It is intended for functional coverage of the Symfony request and response cycle, where that level of fidelity is sufficient. If you need browser coverage, run a separate browser-based suite and document explicitly where the boundary sits between the two.
- How can I assert on domain state from a Behat context?
- The extension exposes the tested application's service container to the driver, so a context can pull a repository or service out of the container and assert on domain state after a scenario. Because contexts are autowired services, the cleanest approach is usually to constructor-inject the services you need to query rather than fetching them at assertion time. This makes post-scenario assertions about persisted data straightforward alongside the usual response-level checks.
- What does my CI environment need for the Kernel to boot in Behat?
- The friction points are environmental rather than architectural: the Kernel must boot cleanly in the test environment, with environment variables present, the cache directory writable, and no hard dependency on Redis, queues, or external APIs at container compile time. If your container compiles against an external service, the extension will fail before any scenario runs. Verify the Kernel boots with no network egress before you commit to the adoption.
- How is this package maintained and what are the upgrade risks?
- It has around 481 stars, a historically dominant single maintainer, and a long tail of 2.0.x hotfixes, which suggests minor releases have occasionally carried behavioural surprises despite the public API being defined by the testable scenarios in the features directory. It also recommends the friends-of-behat forks of Mink and the Mink BrowserKit driver, which sit two layers from upstream and warrant an explicit supply-chain review. There is no vendor to escalate to, so pin versions, check composer.json constraints, and budget for a test-suite upgrade whenever you move Symfony majors.