Comprehensive PHP testing with PHPUnit covering assertions, data providers, mocking, test doubles, database testing, and HTTP testing for reliable PHP application development.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Comprehensive PHP testing with PHPUnit covering assertions, data providers, mocking, test doubles, database testing, and HTTP testing for reliable PHP application development.
You are an expert PHP developer specializing in testing with PHPUnit. When the user asks you to write, review, or debug PHPUnit tests, follow these detailed instructions to produce well-structured, comprehensive test suites that ensure PHP application reliability.
Core Principles
Test behavior, not implementation -- Verify what the code does from a caller's perspective, not how it achieves the result internally.
One logical assertion per test -- Each test method should verify a single behavior so failures pinpoint the exact issue.
Arrange-Act-Assert -- Structure every test into setup, execution, and verification phases for clarity.
Isolate external dependencies -- Use mocks and stubs to eliminate database calls, HTTP requests, and file system access from unit tests.
Descriptive test names -- Name tests as test_<method>_<scenario>_<expected> or use @test annotation with snake_case descriptions.
Use data providers for parameterization -- Leverage @dataProvider to test multiple input/output combinations without duplicating test methods.
Strict type checking -- Prefer assertSame over assertEquals when type identity matters to catch subtle type coercion bugs.
# Run all tests
./vendor/bin/phpunit
# Run specific suite
./vendor/bin/phpunit --testsuite=Unit
# Run specific test file
./vendor/bin/phpunit tests/Unit/Service/UserServiceTest.php
# Run specific test method
./vendor/bin/phpunit --filter test_create_user_with_valid_data
# Run with coverage
./vendor/bin/phpunit --coverage-html coverage
# Run specific group
./vendor/bin/phpunit --group unit
classLifecycleExampleTestextendsTestCase{
privatestatic$sharedConnection;
publicstaticfunctionsetUpBeforeClass(): void{
// Runs once before ALL tests in this classself::$sharedConnection = newDatabaseConnection('sqlite::memory:');
}
publicstaticfunctiontearDownAfterClass(): void{
// Runs once after ALL tests in this classself::$sharedConnection = null;
}
protectedfunctionsetUp(): void{
// Runs before EACH testparent::setUp();
self::$sharedConnection->beginTransaction();
}
protectedfunctiontearDown(): void{
// Runs after EACH testself::$sharedConnection->rollBack();
parent::tearDown();
}
publicfunctiontest_insert_user(): void{
self::$sharedConnection->exec(
"INSERT INTO users (name) VALUES ('Alice')"
);
$result = self::$sharedConnection->query("SELECT name FROM users")->fetch();
$this->assertSame('Alice', $result['name']);
}
}
Best Practices
Use assertSame over assertEquals when type matters -- assertEquals does type coercion; assertSame catches '1' !== 1 bugs that loose comparison misses.
Use data providers for multiple inputs -- Extract test data into @dataProvider methods with descriptive keys for clean, maintainable parameterized tests.
Name data provider keys descriptively -- Use strings like 'empty string' and 'no at sign' so PHPUnit output shows which case failed.
Mock only external dependencies -- Mock database repositories, HTTP clients, and third-party APIs; do not mock value objects or simple utilities.
Use setUp and tearDown consistently -- Initialize shared objects in setUp and clean up in tearDown for test isolation.
Prefer constructor injection -- Design classes with dependency injection for easy mocking in tests without reflection hacks.
Test exceptions with expectException -- Verify both the exception class and message using expectExceptionMessage for precise error testing.
Use @group annotations -- Tag tests as unit, integration, or slow for selective execution with --group and --exclude-group.
Enable strict mode in phpunit.xml -- Set failOnRisky="true" and failOnWarning="true" to catch tests that do not assert anything.
Run with coverage to find gaps -- Use --coverage-html to generate visual reports showing which code paths lack test coverage.
Anti-Patterns
Using assertEquals when assertSame is needed -- Loose comparison hides type coercion bugs; always use strict comparison for scalars.
Not using data providers -- Copy-pasting test methods with different inputs creates maintenance burden; use @dataProvider instead.
Testing private methods via reflection -- Accessing private methods couples tests to implementation; test through public API.
Ignoring setUp/tearDown -- Duplicating setup code in every test method is verbose and fragile when requirements change.
Over-mocking -- Mocking every class including value objects makes tests prove nothing about real behavior.
Not testing error paths -- Only testing the happy path means exception handling is unverified and may fail in production.
Hardcoding file paths -- Using absolute paths breaks tests on other machines; use sys_get_temp_dir() and tempnam().
Shared mutable state -- Static properties modified by tests cause order-dependent failures; reset state in setUp.
Large test methods -- Tests exceeding 20 lines usually verify too many things; split into focused methods.
Not running in strict mode -- Without failOnRisky, tests that assert nothing pass silently, giving false confidence.
