Weave Code
Behat Api Context Laravel Package
macpaw/behat-api-context
MacPaw's Behat API Context provides ready-made Behat steps for testing HTTP APIs in PHP. Build requests with Guzzle, send them, and assert status codes, headers, JSON payloads, and response structure, making REST API acceptance tests quicker to write and maintain.
Behat Context for testing Symfony Api
Frequently asked questions about Behat Api Context
- Is macpaw/behat-api-context a Laravel package?
- No. It is a PHP Composer package distributed as a Symfony Bundle, and its own documentation describes it that way. Laravel has no bundle or DI-extension equivalent, so the package's Symfony-specific value such as container wiring, configuration trees, and service registration has no host in a Laravel application. Only the Behat ApiContext class itself may be portable, and only if it accepts its collaborators through the constructor.
- How do I install macpaw/behat-api-context?
- Install it as a dev dependency with composer require --dev macpaw/behat-api-context. In a Symfony application you also register the bundle and configure it through the Symfony configuration tree. In a Laravel application there is no bundle registration step; you would register the context class directly in behat.yml and construct its dependencies in features/bootstrap. You still need a working Behat runner with behat.yml, bootstrap files, hooks, and transforms.
- Does macpaw/behat-api-context support Laravel 11 and Laravel 12?
- There is no official Laravel support claim. Version 3.1.0 widened dependency constraints to support latest packages, which reduces the prior risk that Symfony component pins would force a downgrade of components shared with Laravel 11 or 12. However, widening a range is a constraint change, not a compatibility guarantee, and there is no evidence in the release notes of a CI matrix exercising the newly admitted Symfony and PHP combinations. Treat it as something to verify in a short spike rather than an assumed compatibility.
- What HTTP methods and assertions does macpaw/behat-api-context support?
- It provides reusable Gherkin steps that exercise GET, POST, PUT, PATCH, and DELETE endpoints. You can send structured JSON payloads and inspect JSON responses, and assert on status codes, headers, and body content or response structure. The goal is readable end-to-end API scenarios without writing custom glue code for every request and assertion.
- Can I use macpaw/behat-api-context in a Laravel app without Symfony?
- Possibly, but only the context class is a candidate for reuse. You would register it directly in behat.yml and construct its dependencies in features/bootstrap, shimming Symfony-typed dependencies with Laravel equivalents such as Laravel's HTTP client behind PSR-18 or a JSON decoder. This is viable only if the class does not reach into Symfony\Component\DependencyInjection or a kernel at runtime. Even then, expect to rewrite a large share of the step vocabulary to match your API conventions.
- How does macpaw/behat-api-context compare to Laravel's built-in HTTP tests?
- Laravel already provides first-class equivalents: $this->getJson() and $this->postJson() on the framework test case, plus Http::fake() for outbound calls. Adopting this package means adding Behat, a non-trivial runner with its own bootstrap, behat.yml, hooks, and transforms, purely to obtain step definitions that are largely mechanical. Fit is low for the framework and moderate for the tooling, and it mainly makes sense in an organization already committed to Behat as a cross-service BDD standard.
- Is macpaw/behat-api-context actively maintained?
- The project is small, with roughly 6 stars and 0 dependents, so maintenance signal is the scarcest thing it has. Version 3.1.0 is a chore and maintenance release that refreshed dependencies, widened constraints, and added an AGENTS.md, and a second-party PR plus a prompt release suggests the maintainer is actively stewarding the repository. That slightly improves the signal but does not turn a reference implementation into a dependency you should build on without evaluation.
- What changed in macpaw/behat-api-context v3.1.0?
- It is a maintenance cut rather than a feature cut: dependency constraints were widened to support latest packages, an AGENTS.md was added, and dependencies were refreshed. There are no new step definitions, no new assertions, and no API surface changes, so the earlier gap analysis and framework mismatch are untouched. The most material change is that the risk of Symfony component pins forcing a downgrade of shared components against Laravel 11 or 12 is now explicitly addressed upstream, turning a likely stop into a verify step.
- How much work is it to adapt macpaw/behat-api-context steps to my API conventions?
- The gap analysis indicates you would rewrite roughly 60 to 80 percent of the step vocabulary for your API conventions, regardless of the v3.1.0 maintenance release. A one-to-two day spike is still the cheapest way to settle the question, and it is now cheaper to run because the dependency constraint audit is less likely to dead-end. Do not commit to Behat adoption before that spike closes.
- What are the alternatives to macpaw/behat-api-context for Laravel API testing?
- For most Laravel teams the strongest alternative is the framework itself: use the test case JSON helpers and Http::fake() with no third-party coupling and no version-conflict surface. If you specifically need Behat, a purpose-built Laravel-native ApiContext of roughly 150 to 300 lines covering request steps, JSON path assertions, status assertions, and auth headers has a lower total cost than hand-wiring this package. Hand-wiring remains an option only when the context class avoids Symfony DI and kernel dependencies, and it still carries Behat adoption, context shimming, and step rewrite costs.
Weaver
How can I help you explore Laravel packages today?