Parameterised / Data-Driven Tests
debt(d7/e3/b3/t3)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints note automated=no, and the code pattern (multiple near-identical test methods differing only in data) is not flagged by PHPUnit or Pest automatically — it requires a human reviewer to notice the duplication and recognise the missing data-provider pattern. No static analysis tool in the provided list catches this structurally.
Closest to 'simple parameterised fix' (e3). The quick_fix describes replacing 5 near-identical test methods with a single @dataProvider or Pest ->with() — this is a small, contained refactor within one test file or component, not a one-liner but not cross-cutting either. It's a clear pattern replacement within one test class.
Closest to 'localised tax' (b3). Misuse (duplicate test methods instead of data providers) imposes a maintenance tax scoped to the test suite for the affected component. It doesn't reach into production code or other system layers; the rest of the codebase is largely unaffected, though the test suite itself becomes harder to maintain over time.
Closest to 'minor surprise' (t3). The misconception field identifies that developers think separate test methods are clearer, plus there are concrete gotchas like data providers needing to be static and dataset keys needing names. These are documented, learnable surprises rather than catastrophic or deeply counterintuitive behaviour — a competent developer will hit one or two edge cases but won't be fundamentally misled.
Also Known As
TL;DR
Explanation
A data provider is a static method returning an array of arrays (or a generator) — each inner array is one test case with its named label. PHPUnit runs the test method once per dataset, naming failures with the dataset key. Use data providers for: boundary values, equivalence classes, valid/invalid input sets, and all-combinations testing. Keep the test logic in the test method; keep the data in the provider. Pest PHP offers ->with() for the same concept with cleaner syntax.
Common Misconception
Why It Matters
Common Mistakes
- Data provider method not declared static — PHPUnit requires static data providers.
- Not naming dataset keys — assertX failed with data set #3 is unhelpful; use 'valid UK postcode' as the key.
- Complex logic in the data provider — providers should only return data, not build objects.
- One data provider shared across unrelated tests — keep providers focused on one test method.
Code Examples
// Copy-pasted test methods — O(n) maintenance:
public function testValidEmailAccepted(): void {
$this->assertTrue(validateEmail('user@example.com'));
}
public function testInvalidEmailWithNoAt(): void {
$this->assertFalse(validateEmail('userexample.com'));
}
public function testInvalidEmailWithNoTld(): void {
$this->assertFalse(validateEmail('user@example'));
}
// ...15 more identical methods/** @dataProvider emailProvider */
public function testEmailValidation(string $email, bool $expected): void {
$this->assertSame($expected, validateEmail($email));
}
public static function emailProvider(): array {
return [
'valid standard email' => ['user@example.com', true],
'valid with subdomain' => ['u@sub.example.com', true],
'invalid no at sign' => ['userexample.com', false],
'invalid no TLD' => ['user@example', false],
'invalid consecutive dots' => ['user..name@ex.com', false],
];
}