Test Naming Conventions

Also Known As

TL;DR

Explanation

PHPUnit test methods should describe the scenario being tested, not the method under test. Pattern: testMethodName is poor (what scenario?); testUserCannotLoginWithWrongPassword is good (describes behaviour). BDD-style: it_rejects_login_with_wrong_password or givenActiveUser_whenWrongPassword_thenAccessDenied (Given/When/Then). The test name should make the failure message self-explanatory — if it fails you know exactly what broke without reading the test body.

Common Misconception

Why It Matters

Common Mistakes

• test + method name: testGetUser() — what scenario? What input? What expected outcome?
• Overly generic names: testHappyPath(), testEdgeCase() — not descriptive.
• Not using @test annotation with natural language: /** @test */ public function user_cannot_login_with_wrong_password().
• Names that describe implementation: testCallsDatabaseQueryOnce() — describe behaviour, not internals.

Code Examples

// Useless test names — failures are opaque:
public function testCalculate(): void { /* What calculation? What case? */ }
public function testUser(): void { /* What about a user? */ }
public function testHappyPath(): void { /* Every test is a happy path */ }
public function testGetUserById(): void { /* What scenario? Exists? Missing? */ }

// Self-documenting test names:
public function testCalculateTotalAppliesVatCorrectlyForUkCustomers(): void { }
public function testGuestUserCannotAccessAdminPanel(): void { }
public function testOrderStatusChangesToProcessingAfterPaymentConfirmed(): void { }
public function testFindByIdReturnsNullWhenUserDoesNotExist(): void { }

// Or BDD-style with @test:
/** @test */
public function it_rejects_checkout_when_cart_is_empty(): void { }

References

• ↗ https://phpunit.readthedocs.io/en/11.0/annotations.html#test

Tags

Related Terms