Testdaten-Builder mit Standardwerten verringern Testausfälle, wenn sich ein Domänenobjekt ändert

Hypothese

Eine Object Mother ist laut Fowlers Beschreibung eine Fabrik, die vertraute, vorgefertigte Objekte ("John, letzte Woche eingestellt") zurückgibt, die von vielen Tests gemeinsam genutzt werden; als deren Schwäche nennt er die starke Kopplung, die entsteht, weil viele Tests von den exakten Daten der Mother abhängen, was eine Änderung dieser Daten heikel macht. Ein Testdaten-Builder nimmt die entgegengesetzte Haltung ein: Er startet von einem gültigen Standardobjekt und stellt eine Methode pro Feld bereit, sodass an_order().with_status("paid").with_lines(3).build() genau die Felder benennt, von denen der Test abhängt, und alles Übrige erbt. Die Hypothese: Wenn einem Domänenobjekt ein Pflichtfeld hinzugefügt wird, sich eine Konstruktorsignatur ändert oder eine Validierungsregel verschärft wird, benötigen builderbasierte Suiten Anpassungen an nur einer Stelle (den Standardwerten des Builders), während Suiten, die Objekte direkt konstruieren, geteilte Fixtures laden oder von vorgefertigten Mother-Instanzen abhängen, Anpassungen benötigen, die proportional zur Anzahl der Tests sind, die das Objekt berühren. Eine zweite Behauptung betrifft die Lesbarkeit: Die in einem Builder-Test benannten Felder sind genau jene, von denen die Prüfung abhängt, sodass eine lesende Person den Test nicht mit einer Fixture-Datei abgleichen muss.

Vorhersage

In der Versionshistorie berühren Commits, die einem Entity ein Pflichtfeld hinzufügen oder dessen Konstruktor ändern, normiert auf die Anzahl der Tests, die das Entity verwenden, weniger Testdateien in Codebasen, in denen das Entity über einen Builder konstruiert wird, als in Codebasen mit direkter Konstruktion, Fixture-Dateien oder einer Object Mother. Personen, die im Review gefragt werden, "von welchen Feldern hängt dieser Test ab?", antworten bei Builder-Tests schneller und genauer.

Vorgeschlagener Test

1. Repositories auswählen, in denen beide Stile nebeneinander bestehen, oder eine Codebasis vor und nach der Einführung von Buildern für eine Gruppe von Entities.
2. Commits identifizieren, die ein Pflichtfeld hinzufügen oder einen Konstruktor ändern; geänderte Testdateien und geänderte Testzeilen pro Commit zählen, gruppiert nach Konstruktionsstil, und auf die Nutzungshäufigkeit normieren.
3. Für die Lesbarkeitsbehauptung reviewenden Personen zusammengehörige Testpaare vorlegen (gleiches Verhalten, beide Stile) und die Zeit messen, die zur Identifikation der Felder gebraucht wird, von denen die Prüfung abhängt.

Status

Es wird kein Ergebnis behauptet. Builder kosten eine Klasse pro Entity und können verschleiern, auf welche Standardwerte sich ein Test stillschweigend verlässt; Object Mothers behalten ihren Wert für geteilte, benannte Beispiele, die in Gesprächen mit Nutzenden vorkommen. Die Hypothese betrifft die Anzahl der Anpassungen bei Änderungen und die Lesbarkeit, nicht die Fehlererkennung.