Symfony Extension Laravel Package

Getting Started

Read this first: this is a Symfony package, not a Laravel package, and it is archived. Zero stars, zero dependents, MIT, no maintainer. For a Laravel codebase the day-to-day leverage is effectively zero — Laravel has no Symfony kernel to boot, no bundle extension system, and no config/services_test.yaml DI to wire into. The closest equivalent in your stack is behat/behat plus a custom extension that boots the Laravel Application and exposes the container, which is a day's work and something you own. Do not add this to a Laravel project.

If you are dealing with a Symfony service inside a Laravel monorepo, or you are evaluating the pattern, the canonical maintained package is friends-of-behat/symfony-extension. Read that one first; this fork is derivative glue. Only pull short-edition/symfony-extension if an existing composer.lock pins it, and in that case vendor the source and pin the exact commit.

Minimal setup, for the Symfony case where this is actually applicable:

composer require --dev short-edition/symfony-extension behat/behat

# behat.yml
default:
  suites:
    default:
      contexts:
        - App\Tests\Behat\ApiContext
  extensions:
    FriendsOfBehat\SymfonyExtension:
      bootstrap: tests/bootstrap.php
      kernel:
        class: App\Kernel
        environment: test
        debug: true

<?php
// tests/bootstrap.php
require __DIR__ . '/../vendor/autoload.php';

The step people miss is registering contexts as services so the extension can autowire them:

# config/services_test.yaml
services:
  _defaults: { autowire: true, autoconfigure: true, public: true }
  App\Tests\Behat\:
    resource: '../tests/Behat/*'

Verify with vendor/bin/behat --definitions and vendor/bin/behat --dry-run, then run one feature with -vv.

Where to look first in the source:

• ServiceContainerInitializer — how the kernel and container are built.
• ContextArgumentResolver — the autowiring mechanism.
• KernelRebooter — per-scenario lifecycle; explains every surprising state issue you will hit.
• The package's own tests/ — the most reliable documentation for this exact fork's config keys.

First useful use case (Symfony): replace a mock-heavy integration test with a feature that boots the kernel, pulls a real service, invokes it, and asserts on the database. For Laravel, the analogous move is a Pest/PHPUnit Feature test hitting the real container — which you already have, and which is why this package is not the answer.

Implementation Patterns

Constructor injection, not container lookups. The extension's value is that it resolves context dependencies from the Symfony container. Do not call $kernel->getContainer()->get('some.id') by string; declare the dependency in the constructor and let the resolver handle it.

final class OrderContext implements Context
{
    public function __construct(
        private OrderRepository $orders,
        private MessageBusInterface $bus,
    ) {}
}

Fresh kernel per scenario. The kernel reboots between scenarios. Treat each as a clean process: no in-memory state carries over, and mocks/overrides must be re-applied in @BeforeScenario, not once at suite start.

HTTP testing without Mink. Skip Mink for API features and drive Symfony's BrowserKit directly:

$client = new KernelBrowser($this->kernel);
$client->request('POST', '/api/orders', server: ['CONTENT_TYPE' => 'application/json'], content: $json);

Only add behat/mink-extension + mink-browserkit-driver if you truly need the Mink session API, and make sure the driver shares this extension's booted kernel rather than booting its own.

Translating the pattern to Laravel. If you decide you want Behat on Laravel, replicate the two ideas this package encodes: (1) a bootstrap that constructs Illuminate\Foundation\Application and boots it with APP_ENV=testing, and (2) a context argument resolver that pulls bindings from the app() container into constructor parameters. You can borrow the structure of ServiceContainerInitializer and ContextArgumentResolver as reference code, but write your own — the Symfony KernelInterface calls inside are not portable.

Database strategy is yours to own. The extension does not do fixtures or transactions. In Symfony: wrap each scenario in a transaction (dama/doctrine-test-bundle) or truncate tables in hooks, and reset the entity manager — a rebooted kernel does not give you a clean EntityManager if something cached it statically. In Laravel the equivalents are RefreshDatabase and DatabaseTransactions, which is another reminder that the testing ergonomics you already have are better.

Console testing. Pull Symfony\Bundle\FrameworkBundle\Console\Application from the booted kernel and use CommandTester. In Laravel the equivalent is $this->artisan(...), which needs none of this.

Gotchas and Tips

• Archived = abandoned. No bug fixes, no security patches, no PHP 8.x / Symfony 6–7 compatibility work. Composer conflicts after a framework or PHP upgrade are the expected failure mode, not an edge case. If you inherit this, register it as a risk item and budget the migration.
• Zero dependents is a real signal. There is no community catching regressions and no upstream to escalate to. Treat the source as your fork the moment it lands in composer.lock.
• Extension namespace mismatch. The example configs reference FriendsOfBehat\SymfonyExtension (a namespace inherited from the upstream package this forks). If autoloading or the extension is not found, check the actual namespace in the package's composer.json and Extension.php — forks frequently keep or change it inconsistently, and the error ("class not found" at bootstrap) is misleading.
• Context wiring failures look like "argument count" errors. A context not registered as a service, or a service not public, surfaces as "cannot autowire argument 0" or "argument 1 does not exist". The fix is almost always in config/services_test.yaml, not your PHP. --definitions will list steps even when wiring is broken; --dry-run is the one that fails.
• Test environment leakage. environment: test and debug: true are required, not optional — without them you can accidentally boot dev/prod config, wire real transports, and send real email. Assert %kernel.environment% === 'test' in a bootstrap hook if you want a guardrail.
• Kernel reboots break static and singleton assumptions. Any service you cache statically, any singleton you grab once in a hook, or any in-memory event listener will silently point at the previous kernel. Re-resolve per scenario.
• Exception swallowing. By default the kernel client catches exceptions and turns them into 500s, which hides the real stack trace. Set catchExceptions(false) while debugging, or check $client->getResponse()->getStatusCode() plus the profiler.
• Extension points if you must vendor. The two worth customizing are the container initializer (to inject your own test services) and the rebooter (to reset state you own, e.g. an in-memory message bus). Do not fork the kernel bootstrapping — that is where Symfony-version coupling lives.
• For Laravel: the honest answer. Do not adopt. Use Pest/PHPUnit with RefreshDatabase, $this->artisan(...), and $this->getJson(...). If you want Behat-style readability, put the acceptance suite behind a custom extension you own; you will spend less time than debugging this package's Symfony assumptions against a Laravel kernel.