Test Data Builders

Also Known As

TL;DR

Explanation

The Object Mother pattern provides pre-built test objects; the Builder pattern gives fine-grained control. A test data builder creates an object with safe defaults and exposes named override methods: UserBuilder::create()->withEmail('test@example.com')->asAdmin()->build(). Only the fields relevant to the test need to be specified — all others use defaults. This keeps tests focused on the behaviour under test rather than construction boilerplate.

Common Misconception

Why It Matters

Common Mistakes

• Not giving the builder sensible defaults — every test having to specify every field defeats the purpose.
• Using the same builder object across multiple tests without resetting state — builders should create fresh objects each time.
• Not naming builder methods semantically: withAdminRole() is clearer than withRole('admin').
• Building complex graphs of related objects inside assertions rather than in setup — obscures what is being tested.

Code Examples

// Test setup noise obscures what is being tested:
public function testAdminCanDeleteUser(): void {
    $admin = new User();
    $admin->id = 1;
    $admin->name = 'Admin';         // Irrelevant
    $admin->email = 'a@example.com'; // Irrelevant
    $admin->createdAt = new DateTime(); // Irrelevant
    $admin->role = 'admin';          // This is the relevant part
    // ... 10 more irrelevant fields
}

// Builder — only relevant data specified:
public function testAdminCanDeleteUser(): void {
    $admin = UserBuilder::create()->asAdmin()->build();
    $user  = UserBuilder::create()->build();

    $this->assertTrue($admin->canDelete($user));
    $this->assertFalse($user->canDelete($admin));
}

References

• ↗ https://www.natpryce.com/articles/000714.html

Tags

Related Terms