- What is codeception/module-symfony used for?
- It is the official Codeception module for testing Symfony applications end to end. It boots your Symfony Kernel inside Codeception and gives tests access to the service container, Doctrine, mailer, security voters, Messenger transports, console commands, sessions, and framework assertions. Use it when you want behaviour-level tests that execute real Symfony code in-process rather than mocking the whole framework.
- How do I install and enable codeception/module-symfony?
- Install it as a dev dependency with composer require --dev codeception/module-symfony. Enable the Symfony module in your Codeception suite configuration and point it at your application Kernel and test environment. Then run your Codeception suite; the module handles kernel bootstrapping and service access for you.
- Does codeception/module-symfony work with Laravel applications?
- Not really for pure Laravel apps. The module is Symfony-native, and many of its newer assertions overlap Laravel features such as $this->mock(), app(), assertSessionHas(), and $this->artisan(). It is most relevant for hybrid stacks, API Platform projects, or Laravel applications that heavily consume Symfony components, but a Laravel-only app should use codeception/module-laravel instead.
- Which Symfony and PHP versions does codeception/module-symfony 3.11 support?
- Version 3.11.0 requires PHP 8.2 or newer and supports Symfony 5.4, 6.4, 7.4, and 8.1. Symfony 5.4 is supported as a legacy LTS stopgap even though its security support ended in late 2025. Some features are version-gated: the runCommand() assertion family needs Symfony 8.1, and Messenger assertions need symfony/messenger 6.3 or newer.
- How do I mock Symfony services in Codeception tests with module-symfony?
- Use mockService() to replace a service in the Symfony container and unmockService() to restore it. In 3.11 these mocks survive kernel reboots, which removes a common pain point when tests trigger multiple requests or console runs. grabContainer() also lets you inspect private services from the test container when you need direct access.
- Can I test Symfony Messenger queues with codeception/module-symfony?
- Yes, if your project uses symfony/messenger 6.3 or newer. The module provides grabMessengerTransport(), seeMessengerTransportContains(), seeMessengerQueueCount(), and consumeMessengerMessages(), with message consumption handled in-process. That lets tests assert what was queued and process envelopes without shelling out to a worker.
- How does runCommand() work and why do my console assertions fail on Symfony 6.4 or 7.4?
- runCommand() executes a Symfony console command and returns an ExecutionResult with separated stdout and stderr, and the related assertions cover success, failure, invalid input, and exact output. These APIs are feature-gated to Symfony 8.1 only, so tests using them will fail or be unavailable on Symfony 6.4 and 7.4. For earlier Symfony versions, use runSymfonyConsoleCommand() instead.
- Is codeception/module-symfony a good fit for testing a Laravel app that uses Symfony components?
- It can be useful if the Laravel app genuinely relies on Symfony components, especially in hybrid or API Platform contexts. However, the Doctrine, Messenger, and security voter methods have little value for Eloquent, Blade, and Sanctum applications. For a normal Laravel codebase, the Laravel-native testing tools are simpler and more direct.
- What are alternatives to codeception/module-symfony for Laravel testing?
- For Laravel applications, codeception/module-laravel is the natural alternative, often paired with Pest or PHPUnit and Laravel's HTTP, database, and queue fakes. For Symfony, teams also use Symfony's PHPUnit Bridge, Panther for browser tests, or Behat for behaviour-driven suites. Choose module-symfony when you specifically want Codeception-style end-to-end tests with deep Symfony Kernel access.
- Is codeception/module-symfony maintained and safe to upgrade from 3.10 to 3.11?
- Yes, it is maintained under the Codeception organisation and 3.11.0 is an additive release with no breaking changes, no new configuration options, and no new traits. Upgrading from 3.10.x is a composer update plus a full suite run, assuming you are already on PHP 8.2 or newer. Plan around Symfony 5.4 being end-of-life and around Symfony 8.1-only console assertions if you maintain older Symfony versions.