Faker für realistische Testdaten in PHP-Projekten einsetzen

1. Warum handgeschriebene Dummy-Werte gefährlich sind

In vielen gewachsenen Testsuiten finden sich Zeilen wie $name = 'Test Test' oder $email = 'test@test.de'. Solche Werte erfüllen zwar formal den Zweck, eine Variable zu befüllen, verschleiern aber systematisch echte Bugs. Eine Validierungsfunktion für Namen mit Umlauten, Bindestrichen oder mehreren Vornamen wird nie getestet, wenn der einzige jemals verwendete Name konsequent 'Test Test' lautet.

Noch problematischer wird es, wenn mehrere Tests denselben statischen Wert wiederverwenden und dadurch versehentlich Kollisionen kaschieren, etwa wenn eine E-Mail-Eindeutigkeitsprüfung nie fehlschlägt, weil in allen Tests zufällig dieselbe Adresse verwendet wird, oder umgekehrt eine echte Kollision nie auftritt, weil jeder Test bewusst eine andere fest kodierte Adresse benutzt. Beide Fälle liefern grüne Tests, ohne dass die eigentliche Geschäftslogik jemals unter realistischen Bedingungen geprüft wurde. Erschwerend kommt hinzu, dass solche Dummy-Werte sich in gewachsenen Projekten über Jahre hinweg per Copy-Paste vermehren, sodass am Ende Dutzende Tests denselben blinden Fleck teilen, ohne dass es jemandem auffällt.

2. Faker installieren und erste Schritte

Die heute gepflegte Bibliothek heißt fakerphp/faker und ist der Nachfolger des nicht mehr aktiv entwickelten fzaninotto/faker. Sie wird als Dev-Abhängigkeit über Composer installiert, da Testdaten-Generierung im Produktivcode nichts zu suchen hat. Der Einstiegspunkt ist immer Faker\Factory::create(), das eine Faker-Generator-Instanz mit deutscher oder englischer Locale zurückgibt.

Ein zentraler Faker-Generator kennt Dutzende Provider für Namen, Adressen, Firmen, Internet-Daten, Zahlen und sogar branchenspezifische Formate wie IBAN-Nummern oder Barcodes. Der Zugriff erfolgt über magische Properties wie $faker->name oder explizite Methoden wie $faker->numberBetween(10, 500), was den Umgang im Alltag sehr kompakt macht.

<?php

declare(strict_types=1);

namespace Tests\Support;

use Faker\Factory;
use Faker\Generator;

/**
 * Zentrale Faker-Factory fuer die gesamte Testsuite.
 */
final class TestDataFactory
{
    private static ?Generator $faker = null;

    public static function faker(): Generator
    {
        if (self::$faker === null) {
            self::$faker = Factory::create('de_DE');
            self::$faker->seed(20260807);
        }

        return self::$faker;
    }
}

3. Feste Seeds für deterministische Tests

Der größte Einwand gegen zufällige Testdaten lautet zurecht: Ein Test, der heute grün ist, darf morgen nicht ohne erkennbaren Grund rot werden. Faker löst dieses Problem über die seed()-Methode. Wird der Zufallsgenerator mit demselben Seed-Wert initialisiert, liefert er bei jedem Testlauf exakt dieselbe Sequenz von 'zufälligen' Werten, unabhängig davon, ob der Test lokal, in der CI-Pipeline oder in drei Monaten erneut ausgeführt wird.

In der Praxis setzt man den Seed am besten zentral in der Bootstrap-Datei oder in einer gemeinsamen setUp()-Basisklasse, statt ihn in jedem einzelnen Test manuell zu setzen. So bleibt die Reproduzierbarkeit garantiert, während die einzelnen Tests weiterhin von realistischer Datenvielfalt profitieren, ohne dass jemand die konkreten generierten Werte im Voraus kennen oder dokumentieren müsste. Wichtig ist außerdem, denselben Seed auch in der CI-Pipeline zu verwenden wie lokal, da unterschiedliche Seeds zwischen den Umgebungen sonst genau die Reproduzierbarkeit wieder zunichtemachen, die der Seed eigentlich garantieren soll.

<?php

declare(strict_types=1);

namespace Tests\Unit\Customer;

use App\Customer\CustomerRegistrar;
use PHPUnit\Framework\TestCase;
use Tests\Support\TestDataFactory;

final class CustomerRegistrarTest extends TestCase
{
    public function testRegistersCustomerWithRealisticData(): void
    {
        $faker = TestDataFactory::faker();

        $registrar = new CustomerRegistrar();
        $customer = $registrar->register(
            firstName: $faker->firstName(),
            lastName: $faker->lastName(),
            email: $faker->unique()->safeEmail(),
            street: $faker->streetAddress(),
            postcode: $faker->postcode(),
            city: $faker->city(),
        );

        self::assertNotEmpty($customer->getFullName());
        self::assertStringContainsString('@', $customer->getEmail());
    }
}

4. Eigene Provider für domänenspezifische Daten

Fakers Standard-Provider decken generische Daten wie Namen und Adressen ab, aber jedes Projekt hat auch domänenspezifische Konzepte, etwa SKU-Formate, Kundennummern oder Produktkategorien. Für solche Fälle lassen sich eigene Provider-Klassen schreiben, die den generischen Faker-Generator erweitern und projektspezifische Erzeugungsmethoden anbieten.

Ein eigener Provider kapselt dabei nicht nur das Format, sondern auch die fachlichen Regeln, etwa dass eine SKU immer mit einem zweistelligen Kategorie-Präfix beginnt und danach eine sechsstellige laufende Nummer folgt. Das verhindert, dass in verschiedenen Tests leicht unterschiedliche, teils ungültige SKU-Formate handgeschrieben werden, und macht gleichzeitig sichtbar, welche Formatregeln in der Domäne überhaupt gelten. Ein weiterer Vorteil ist, dass sich Formatänderungen, etwa eine Erweiterung des Kategorie-Präfixes von zwei auf drei Buchstaben, an genau einer zentralen Stelle nachziehen lassen, statt in Dutzenden verstreuten Testdateien.

<?php

declare(strict_types=1);

namespace Tests\Support\Faker;

use Faker\Provider\Base;

/**
 * Domaenenspezifischer Faker-Provider fuer Produkt-SKUs.
 */
final class ProductProvider extends Base
{
    private const CATEGORY_PREFIXES = ['EL', 'MO', 'GA', 'BU'];

    public function sku(): string
    {
        $prefix = static::randomElement(self::CATEGORY_PREFIXES);
        $number = str_pad((string) $this->generator->numberBetween(1, 999999), 6, '0', STR_PAD_LEFT);

        return sprintf('%s-%s', $prefix, $number);
    }
}

5. Faker in PHPUnit-Datenprovidern nutzen

Ein häufiger Fehler ist der Versuch, Faker direkt in einer #[DataProvider]-Methode aufzurufen, da diese Methode vor jedem Testlauf einmalig ausgewertet wird und die generierten Werte dann für mehrere Testdurchläufe gleichzeitig eingefroren werden, was den eigentlichen Zweck realistischer Streuung untergräbt. Besser ist es, im Datenprovider nur die Struktur oder feste Randfälle zu definieren und Faker gezielt innerhalb der Testmethode selbst aufzurufen.

Für Fälle, in denen tatsächlich viele zufällige Kombinationen als Datenprovider-Zeilen gebraucht werden, etwa um eine Validierungsfunktion mit zwanzig unterschiedlichen, aber realistischen Adressen zu prüfen, kann man Faker mit festem Seed direkt beim Aufbau des Datenprovider-Arrays verwenden. Weil der Seed fix ist, bleibt auch diese Liste über Testläufe hinweg stabil.

<?php

declare(strict_types=1);

namespace Tests\Unit\Validation;

use App\Validation\AddressValidator;
use Faker\Factory;
use PHPUnit\Framework\Attributes\DataProvider;
use PHPUnit\Framework\TestCase;

final class AddressValidatorTest extends TestCase
{
    public static function validAddressProvider(): array
    {
        $faker = Factory::create('de_DE');
        $faker->seed(4242);

        $cases = [];
        for ($i = 0; $i < 20; $i++) {
            $cases[] = [$faker->streetAddress(), $faker->postcode(), $faker->city()];
        }

        return $cases;
    }

    #[DataProvider('validAddressProvider')]
    public function testAcceptsValidAddress(string $street, string $postcode, string $city): void
    {
        $validator = new AddressValidator();

        self::assertTrue($validator->isValid($street, $postcode, $city));
    }
}

6. Realistische Preise und Zahlenformate erzeugen

Für E-Commerce-Projekte wie Magento-Shops sind realistische Preise besonders wichtig, weil Rundungsfehler und Formatierungsprobleme oft erst bei bestimmten Kombinationen aus Nachkommastellen und Steuersätzen auffallen. Faker bietet mit randomFloat() und numberBetween() die Bausteine, um sowohl typische Preise als auch bewusste Randfälle wie sehr kleine oder sehr große Beträge zu erzeugen.

Sinnvoll ist es, diese Bausteine in eine eigene Hilfsmethode zu kapseln, die auch garantiert gültige, auf zwei Nachkommastellen gerundete Centbeträge liefert, statt Faker-Rohwerte direkt in die Tests zu übernehmen. So bleibt sichergestellt, dass generierte Preise tatsächlich der Formatregel entsprechen, die auch im Produktivsystem gilt, statt zufällig auch technisch unmögliche Werte wie drei Nachkommastellen zu erzeugen.

<?php

declare(strict_types=1);

namespace Tests\Support\Faker;

use Faker\Generator;

/**
 * Hilfsfunktionen fuer realistische, geschaeftlich gueltige Preise.
 */
final class PriceFaker
{
    public function __construct(private readonly Generator $faker)
    {
    }

    public function grossPrice(float $min = 1.0, float $max = 999.99): float
    {
        return round($this->faker->randomFloat(2, $min, $max), 2);
    }
}

7. Grenzen von Faker im Testalltag

Faker eignet sich hervorragend für generische, breit gestreute Daten, ersetzt aber keine gezielten Grenzwerttests. Wer explizit prüfen will, wie eine Funktion mit einem leeren String, einem 256 Zeichen langen Namen oder einem negativen Preis umgeht, sollte diese Fälle weiterhin bewusst und explizit als eigene Testfälle formulieren, statt zu hoffen, dass Faker diese Randfälle zufällig einmal produziert.

Ebenso ungeeignet ist Faker für Tests, die eine exakte, fachlich vorgegebene Eingabe-Ausgabe-Beziehung prüfen sollen, etwa eine Steuerberechnung mit einem gesetzlich fixierten Prozentsatz. Hier gehört ein fester, dokumentierter Testwert ins Testcase, weil die Nachvollziehbarkeit des erwarteten Ergebnisses wichtiger ist als realistische Datenvielfalt. Eine gute Faustregel lautet: Immer dann, wenn das erwartete Ergebnis selbst berechnet statt einfach nur strukturell geprüft wird, sollte die Eingabe fest und dokumentiert sein, nicht zufällig generiert.

8. Best Practices für den Team-Einsatz

Ein zentraler Faker-Wrapper pro Projekt, wie im ersten Beispiel gezeigt, verhindert, dass jeder Entwickler eigene Locale-Einstellungen oder Seeds verwendet und dadurch die Testläufe im Team uneinheitlich werden. Ebenso wichtig ist, den Seed-Wert bei Bedarf zu erhöhen oder zu ändern, wenn eine bestimmte Zufallssequenz unerwartet zu einer echten Datenkollision führt, etwa zwei zufällig gleiche E-Mail-Adressen in einem Uniqueness-Test.

Empfehlenswert ist außerdem, in der Team-Dokumentation kurz festzuhalten, welcher Seed-Wert aktuell verwendet wird und warum, damit ein Wechsel des Seeds als bewusste, nachvollziehbare Entscheidung im Code-Review sichtbar wird und nicht als versehentliche Nebenwirkung einer anderen Änderung durchrutscht.

9. Fazit: Realismus und Reproduzierbarkeit verbinden

Faker löst den scheinbaren Widerspruch zwischen realistischen Testdaten und deterministischen, wiederholbaren Testläufen elegant über feste Seeds. Für Magento- und andere PHP-Projekte lohnt sich der Umstieg von handgeschriebenen Dummy-Werten besonders bei Validierungslogik, Formularverarbeitung und allem, was mit personenbezogenen oder adressbezogenen Daten zu tun hat.

Der Einstieg erfordert wenig Aufwand: eine zentrale Factory-Klasse, ein fester Seed und bei Bedarf ein oder zwei eigene Provider für domänenspezifische Formate reichen meist aus, um eine Testsuite spürbar aussagekräftiger zu machen, ohne die Nachvollziehbarkeit einzelner Testläufe zu gefährden.

10. Zusammenfassung

11. FAQ: Faker für Testdaten: Das Wichtigste auf einen Blick