Testdaten mit Buildern aufbauen: gültige Vorgaben, benannte Abweichungen

Ziel

Tests, deren Aufbau nur die für die Prüfung relevanten Werte nennt und die bei Änderungen am Datenmodell an genau einer Stelle angepasst werden.

Voraussetzungen

Entitäten mit klaren Gültigkeitsregeln (welche Felder sind Pflicht, welche Kombinationen sind erlaubt); eine Sprache, in der sich verkettete Aufrufe oder benannte Argumente ausdrücken lassen; ein Testrahmen, der die Objekte ohne Datenbank oder mit einer Wegwerf-Datenbank aufbauen kann.

Schritte

1. Für jede Entität, die in mehr als einer Handvoll Tests vorkommt, einen Builder anlegen: eine_bestellung() liefert eine gültige Bestellung mit sinnvollen Vorgaben (ein Artikel, Status «offen», Kundin vorhanden).
2. Pro Feld eine benannte Setzmethode (.mit_status("bezahlt"), .mit_positionen(3)) oder – in Sprachen mit benannten Argumenten – eine Funktion mit Vorgabewerten. Der Builder erzeugt das Objekt erst bei .bauen().
3. Im Test nur setzen, was die Aussage betrifft: Ein Test über Mahnungen setzt Fälligkeit und Status, nichts sonst. Was nicht genannt ist, ist für den Test unerheblich – das ist die Leseregel.
4. Zufall vermeiden oder festnageln: Vorgaben sind deterministisch; wo Eindeutigkeit gebraucht wird (E-Mail-Adresse), ein Zähler statt Zufall.
5. Verwandte Objekte über andere Builder aufbauen (.mit_kundin(eine_kundin().aus_land("CH"))), damit Beziehungen gültig bleiben.
6. Bei einer Änderung am Modell (neue Pflichtspalte, geänderter Konstruktor) zuerst den Builder anpassen, dann die Tests laufen lassen; nur Tests, die das neue Feld inhaltlich betreffen, werden angefasst.
7. Geteilte «kanonische» Objekte (die Kundin Meier, die immer vorkommt) nur dort behalten, wo sie ein gemeinsames Vokabular mit Fachpersonen sind – und auch diese über den Builder erzeugen.

Erwartetes Ergebnis

Ein Test liest sich als «gegeben eine Bestellung mit Status bezahlt und drei Positionen, wenn …, dann …»; Modelländerungen erzeugen wenige, lokale Testanpassungen; Fixture-Dateien mit hunderten Zeilen entfallen.

Grenzen und Prüfbasis

Das Muster grenzt sich von der Object Mother ab, die Martin Fowler als Fabrik für vertraute, fertige Beispielobjekte beschreibt und deren Nachteil er als enge Kopplung benennt: Viele Tests hängen an den exakten Daten der Mother, was deren Änderung heikel macht. Ein Builder pro Entität kostet Pflege und kann verdecken, auf welche Vorgaben ein Test stillschweigend baut. Ob Builder die Zahl der Teständerungen tatsächlich senken, ist im Wiki als eigene Hypothese formuliert, nicht als Befund; eine Messung wird nicht behauptet.