- What is codeception/module-laravel used for?
- It is the official Codeception module that bootstraps a Laravel application inside your test suites, so functional and acceptance tests run against a real, initialized framework instance. It exposes the application container and adds helpers for HTTP requests, database transactions, authentication, mail, events, and queues. It is most useful when Codeception is already your test harness or when you need end-to-end tests spanning Laravel and non-Laravel services.
- How do I install codeception/module-laravel?
- Install it as a dev dependency with Composer, for example composer require --dev codeception/module-laravel:^3.2. It is a testing-only package, so it should never be in your production dependencies. After installation you enable the module in your Codeception suite configuration and point the bootstrap at your Laravel application.
- Which Laravel, PHP, and Codeception versions are supported by 3.2.1?
- Version 3.2.1 is a patch release containing a single fix for an implicit null guard name, with no public API changes or deprecations. Exact Laravel, PHP, and Codeception constraints are declared in the package composer.json, so check that file and the README rather than assuming. Pin the version and validate the full matrix in CI before rolling it out broadly.
- How do I enable the Laravel module in a Codeception suite?
- Add Codeception\Module\Laravel to the enabled modules list in your suite YAML and configure the Laravel connector along with the bootstrap path to your application. You can then customize the environment, bootstrap, and cleanup behavior through the module configuration. Start with a small smoke suite covering auth, HTTP, and database behavior before expanding coverage.
- How does codeception/module-laravel handle database transactions and cleanup?
- The module wraps tests in database transactions and supports ORM and query cleanup so changes made during a test are rolled back afterwards. This keeps tests isolated without you manually truncating tables between runs. If you use multiple connections or non-transactional operations, verify your cleanup strategy and watch for state leaking between tests.
- How do I log in as a user or test named auth guards?
- The module provides auth helpers that log a user in or act as an authenticated user for the duration of a test. Named guards have historically been an edge case, which is exactly what the 3.2.1 fix addresses for implicit null guard names. If your application uses multiple guards, add an explicit regression test for guard resolution instead of assuming the default behavior covers it.
- Can I use codeception/module-laravel alongside PHPUnit or Pest?
- Yes. Codeception and PHPUnit can coexist under Composer, so you can run a Codeception suite next to an existing PHPUnit or Pest suite. The recommended path is incremental: port a small smoke suite first, then expand rather than rewriting existing feature tests in one go. Be aware that PHPUnit-only teams will need time to learn Codeception's actors and Cest/CEPT formats.
- How do I test mail, events, queues, and HTTP responses with this module?
- The module exposes Laravel utilities and facades so you can assert on mail, events, queues, and HTTP responses directly from your tests. Because the framework is booted for each test, fakes and facade swaps behave the same way they do in the application. This lets you write expressive assertions without wiring up the container manually.
- Why am I getting auth guard errors, and what changed in 3.2.1?
- Release 3.2.1 is a single bug fix for an implicit null guard name, which points to named-guard resolution being an area of active maintenance. If you hit guard errors, confirm which guard the test should use and whether a guard name is being passed implicitly. Upgrading to 3.2.1 plus a dedicated regression test is the safest way to confirm the fix applies to your configuration.
- Is codeception/module-laravel actively maintained, and what are the alternatives?
- It is community-maintained under the Codeception organization via GitHub issues and pull requests, with no vendor SLA, so assign internal ownership for upgrade triage. Its main alternative is staying on Laravel's default Pest or PHPUnit stack, which avoids introducing a second testing abstraction. Choose this module when Codeception is already your harness or you need mixed-stack end-to-end testing.