PHP Testing Frameworks: 11 Tools for Unit, BDD and E2E Tests

1. PHPUnit

PHPUnit is the xUnit-style framework that much of PHP testing builds on: Pest runs on it, Codeception's unit tests use it, and Infection mutates code against it. Each test class extends TestCase, and assertion methods such as assertSame() check the results.

According to the PHPUnit supported versions page, PHPUnit 13 was released on February 6, 2026 and needs PHP 8.4 or later, while PHPUnit 12 needs PHP 8.3.

This test checks an App\Calculator class whose add() method returns the sum of two integers, using two named data sets:

<?php
use App\Calculator;
use PHPUnit\Framework\Attributes\DataProvider;
use PHPUnit\Framework\TestCase;

final class CalculatorTest extends TestCase
{
    public static function sums(): array
    {
        return ['positives' => [2, 2, 4], 'negatives' => [-1, -1, -2]];
    }

    #[DataProvider('sums')]
    public function testAdds(int $a, int $b, int $expected): void
    {
        $this->assertSame($expected, (new Calculator())->add($a, $b));
    }
}

Running ./vendor/bin/phpunit tests with PHPUnit 13.4.1 printed:

PHPUnit 13.4.1 by Sebastian Bergmann and contributors.

Runtime:       PHP 8.4.26

..                                                            2 / 2 (100%)

Time: 00:00.001, Memory: 20.00 MB

OK (2 tests, 2 assertions)

Older tutorials put the data provider in a doc-comment, as /** @dataProvider sums */. With that comment in place of the attribute, PHPUnit 13.4.1 ignored the provider and ran the test once with no arguments, failing with ArgumentCountError: Too few arguments ... 0 passed ... and exactly 3 expected.

The PHPUnit 12 release announcement confirms that support for annotations has been removed, so convert doc-comments to attributes before you upgrade.

2. Pest

Pest is a function-based framework that runs on top of PHPUnit: tests are it() closures with expect() chains instead of classes. Installing pestphp/pest 5.3.1 pulled in PHPUnit 13.4.1 as its engine, and Pest 5 needs PHP 8.4 or later. Here is the same calculator test in Pest:

<?php
use App\Calculator;

it('adds two numbers', function (int $a, int $b, int $expected) {
    expect((new Calculator())->add($a, $b))->toBe($expected);
})->with([
    'positives' => [2, 2, 4],
    'negatives' => [-1, -1, -2],
]);

Pest names each data set in its output. Running ./vendor/bin/pest printed:

   PASS  Tests\CalculatorTest
  ✓ it adds two numbers with dataset "positives"                   0.01s
  ✓ it adds two numbers with dataset "negatives"

  Tests:    2 passed (2 assertions)
  Duration: 0.26s

Pest's browser testing plugin, introduced in Pest 4, runs browser tests through Playwright in Chrome, Firefox, or Safari, so browser checks can live in the same test suite as your other Pest tests.

PHPUnit vs Pest: Which Should You Use?

Both run the same assertions on the same engine, so the comparison comes down to syntax and tooling:

Because Pest also runs PHPUnit classes, an existing suite can move to Pest one file at a time.

3. Codeception

Codeception's own site calls it a BDD-styled PHP testing framework. It covers unit tests built on PHPUnit, functional tests through modules for Symfony, Laravel, and Yii, acceptance tests in a real browser through its WebDriver module, and REST or SOAP API tests.

Tests are Cest classes in which an actor, $I, performs readable steps, and this guide to PHP testing with Codeception covers setup in depth. The acceptance suite below runs on TestMu AI's Selenium grid, reading credentials from environment variables once codeception.yml lists params: - env:

actor: AcceptanceTester
suite_namespace: Tests\Acceptance
modules:
    enabled:
        - WebDriver:
            url: https://www.testmuai.com
            host: '%LT_USERNAME%:%LT_ACCESS_KEY%@hub.lambdatest.com'
            port: 443
            protocol: https
            browser: chrome
            capabilities:
                browserVersion: latest
                'LT:Options':
                    platformName: Windows 11
                    build: PHP Testing Frameworks
                    name: Codeception SimpleFormCest

<?php
namespace Tests\Acceptance;

use Tests\Support\AcceptanceTester;

final class SimpleFormCest
{
    public function showsTypedMessage(AcceptanceTester $I): void
    {
        $I->amOnPage('/selenium-playground/simple-form-demo/');
        $I->waitForJS('return document.readyState === "complete";', 10);
        $I->fillField('input#user-message', 'Hello from Codeception');
        $I->click('#showInput');
        $I->see('Hello from Codeception', '#message');
    }
}

Running codecept run Acceptance --steps with Codeception 5.3.7 printed each step in plain English and passed on Chrome 154 on Windows 11 (excerpt):

Scenario --
 I am on page "/selenium-playground/simple-form-demo/"
 I wait for js "return document.readyState === "complete";",10
 I fill field "input#user-message","Hello from Codeception"
 I click "#showInput"
 I see "Hello from Codeception","#message"
 PASSED

TestMu AI's Codeception integration guide shows the same WebDriver module settings for running Codeception on the grid.

4. Behat

Behat runs scenarios written in Gherkin, the Given/When/Then format, and maps each step to a PHP method in a context class.

The Behat 4.0 release notes say contexts no longer support PHPUnit assertions unless you add the behat/phpunit-assertions-extension package.

This feature and context ran on Behat 4.0.0, with steps bound through PHP 8 attributes:

Feature: Shopping cart
  Scenario: Add an item to the cart
    When I add "MacBook Air" to the cart
    Then the cart should contain 1 item

<?php
use Behat\Behat\Context\Context;
use Behat\Step\{Then, When};

final class FeatureContext implements Context
{
    private array $cart = [];

    #[When('I add :product to the cart')]
    public function add(string $product): void { $this->cart[] = $product; }

    #[Then('the cart should contain :count item(s)')]
    public function hasItems(int $count): void
    {
        count($this->cart) === $count
            or throw new RuntimeException('Cart count mismatch');
    }
}

Feature: Shopping cart

  Scenario: Add an item to the cart      # features\cart.feature:2
    When I add "MacBook Air" to the cart # FeatureContext::add()
    Then the cart should contain 1 item  # FeatureContext::hasItems()

1 scenario (1 passed)
2 steps (2 passed)
0m0.03s (10.47Mb)

Changing the expected count to 2 failed the Then step with Cart count mismatch (RuntimeException) and exit code 1, so a wrong count does fail the scenario. TestMu AI's Behat guide covers running Behat browser tests on the grid, including locally hosted pages.

5. PHPSpec

PHPSpec's documentation describes it as a toolset to drive emergent design by specification. You first describe the behavior of an object you are about to write, then write just enough code to meet that spec, then refactor.

The same documentation pairs it with story-level tools such as Behat instead of replacing them: specs shape how a class works, while Behat scenarios check what users see.

6. Kahlan

Kahlan is a unit and BDD framework with RSpec-style describe() and it() blocks. Its README says it can stub or monkey patch code without any PECL extension, including replacing core functions and classes on the fly, so specs rarely need a separate mocking library.

It is also the least installed framework in the table above, so check that its small community fits your support needs before adopting it.

7. Laravel Dusk

Laravel's Dusk documentation describes it as a browser automation and testing API that needs no JDK or Selenium install by default, because it runs a standalone ChromeDriver.

The same documentation shows how to edit the driver() method in tests/DuskTestCase.php so Dusk connects to any Selenium-compatible server instead.

Install it with composer require laravel/dusk --dev, then run php artisan dusk:install to create tests/Browser and download ChromeDriver. This guide to getting started with Laravel testing walks through Dusk tests in a real app, and TestMu AI's Laravel Dusk guide covers the driver change for the grid.

8. Symfony Panther

Symfony Panther's README calls it a standalone library to scrape websites and run end-to-end tests using real browsers, driving Chrome and Firefox through the W3C WebDriver protocol. Because it is standalone, it also works in PHP projects that do not use Symfony.

9. php-webdriver

php-webdriver is the PHP language binding for Selenium WebDriver and, per its README, works with Selenium server 2.x, 3.x, and 4.x. It replaced facebook/webdriver, which Packagist now marks as abandoned in favor of php-webdriver/webdriver.

Other tools build on it: Laravel's Dusk documentation creates the driver with its RemoteWebDriver class, and installing Codeception's WebDriver module pulled in php-webdriver 1.16.0 as a dependency.

10. Mockery

Mockery's README describes it as a simple yet flexible mock object framework for PHPUnit, PHPSpec, or any other test framework. In this test, App\Order::checkout() charges an App\PaymentGateway, an interface with one charge(int $amount): bool method, and the mock replaces the real gateway:

<?php
use App\Order;
use App\PaymentGateway;
use Mockery\Adapter\Phpunit\MockeryPHPUnitIntegration;
use PHPUnit\Framework\TestCase;

final class OrderTest extends TestCase
{
    use MockeryPHPUnitIntegration;

    public function testCheckoutChargesTheGatewayOnce(): void
    {
        $gateway = Mockery::mock(PaymentGateway::class);
        $gateway->shouldReceive('charge')->once()->with(100)
            ->andReturn(true);
        $this->assertTrue((new Order($gateway))->checkout(100));
    }
}

The MockeryPHPUnitIntegration trait checks expectations when the test ends. With the checkout() call removed, the test failed with InvalidCountException: Method charge(100) ... should be called exactly 1 times but called 0 times.

11. Infection

Infection is a mutation testing framework: it changes your code in small ways, such as turning > into >=, and reruns the tests against each mutant. Infection's guide defines the Mutation Score Indicator (MSI) as the share of mutants the tests detect and lists PHP 8.3 or later plus a coverage driver as requirements.

The guide lists Xdebug, PCOV, and phpdbg as drivers, but PHPUnit 13.4.1 rejected phpdbg with No code coverage driver available that supports line coverage, so use PCOV or Xdebug with PHPUnit 13. This discount class had two passing tests, for orders of 150 and 50, and full line coverage:

<?php
namespace App;

final class Discount
{
    // Orders above 100 get 10 percent off
    public function apply(int $total): float
    {
        return $total > 100 ? $total * 0.9 : (float) $total;
    }
}

Running ./vendor/bin/infection src/Discount.php with PCOV 1.0.12 produced this excerpt, the escaped-mutant diffs and the summary:

-        return $total > 100 ? $total * 0.9 : (float) $total;
+        return $total >= 100 ? $total * 0.9 : (float) $total;

-        return $total > 100 ? $total * 0.9 : (float) $total;
+        return $total > 100 ? $total * 0.9 : $total;

5 mutations were generated:
       3 mutants were killed by Test Framework
       2 covered mutants were not detected

Metrics:
         Mutation Code Coverage: 100%
         Covered Code MSI: 60%

The first survivor is a real gap: no test checks an order of exactly 100, so a >= bug would ship. The second is an equivalent mutant, because the float return type already converts the integer, which makes the (float) cast dead code. After adding a test for 100 and deleting the cast, Infection generated 4 mutants and the tests killed all 4.