Test-Fixtures mit Identitätsdaten sind die Zeilen, die eine Testsuite dauerhaft hält: die Person, die alt genug ist, die Person, die es nicht ist, die Kundin, deren Adresse eine einzige ununterbrochene Zeichenfolge ist, das Konto ohne Familiennamen. Sie sind billig anzulegen und leicht schlecht zu halten, und ein Fixture-Satz, der aus dem Tritt mit dem Produkt gerät, ist schlimmer als gar keine Fixtures, weil er falsche Sicherheit verleiht.
Dieser Leitfaden behandelt, wie Sie Identitätsdatensätze in einem Fixture-Satz ordnen, welche Randfälle es wert sind, behalten zu werden, und wie Sie verhindern, dass die Sammlung still verrottet.
Was gehört in eine Fixture und was in einen Erzeuger?
Eine Fixture wird verwendet, wenn der Test ein bestimmtes Ergebnis zusichert, und ein Erzeuger wird verwendet, wenn der Test nach unbekannten Eingabeproblemen sucht. Der Unterschied betrifft nicht Größe oder Förmlichkeit, sondern die Frage, ob jemand die Eingabe vorher kennen muss.
Damit sind Fixtures für Verhalten da: Gegeben diese Person, muss das System diesen Zweig nehmen. Erzeuger sind für Erkundung da: Füttern Sie das System mit vielen plausiblen Personen und sehen Sie, was bricht. Ein Test, der eine Antwort zusichert, seine Eingabe aber zufällig zieht, testet nicht das Verhalten, das er zu testen behauptet, weil der nächste Lauf einen anderen Zweig durchlaufen und den vom Autor gemeinten Fall nicht mehr abdecken kann.
Die meisten Suiten brauchen beides, und die nützliche Konvention ist, den Unterschied sichtbar zu machen. Fixtures leben in Dateien mit stabilen Werten und lesbaren Namen. Erzeugte Datensätze leben in einem Schritt, der zur Testzeit läuft. Beides in einer Datei zu mischen, macht eine Suite sechs Monate später unlesbar.
Warum macht Zufall bei jedem Lauf Fehler unwiederholbar?
Weil der Fehlerbericht keine Eingabe enthält. Ein Test, der bei jedem Lauf einen frischen Datensatz zieht, liefert einen Stapelbericht, einen Screenshot und sonst nichts; der nächste Lauf besteht womöglich, und die Entwicklerin rätselt, ob die Korrektur gewirkt hat oder ob sich die Würfel geändert haben.
Das ist die häufigste Quelle unzuverlässiger Tests in datenlastigen Systemen, und der Schaden summiert sich. Entwickler lernen, fehlschlagende Tests so lange erneut zu starten, bis sie grün sind, was das ganze Team allmählich dazu erzieht, das Signal zu ignorieren, für das die Suite existiert. Wiederholbarkeit ist hier keine Nettigkeit, sondern die Eigenschaft, die den Rest der Suite bedeutsam macht.
Die Lösung ist, die Eingabe festzunageln und die Variation aus einer kontrollierten Quelle kommen zu lassen. Wird ein Datensatz erzeugt statt von Hand geschrieben, liefert die Ableitung aus einem festen Schlüssel bei jedem Lauf dieselbe Person, eine Zusicherung bleibt stabil und ein Fehlerbericht kann den genauen Datensatz benennen, den er gesehen hat.
Wie sollten Fixture-Datensätze benannt und gruppiert werden?
Benennen Sie jeden Datensatz nach der Situation, für die er existiert, nicht nach den Werten, die er enthält. Ein Datensatz mit einem Namen wie Bewerberin über achtzehn sagt der nächsten Leserin, wofür er da ist; ein nach einem Nachnamen benannter Datensatz sagt nichts und wird binnen eines Monats für den falschen Zweck wiederverwendet.
Die Gruppierung folgt derselben Logik. Eine Fixture-Datei pro Funktion oder Szenario, die nur die Personen enthält, die dieses Szenario braucht, hält die Datei lesbar und macht offensichtlich, wenn ein Datensatz ungenutzt geworden ist. Eine einzige riesige Datei mit hundert Datensätzen erzeugt Suiten, in denen niemand sagen kann, welche Fixture noch zählt, sodass niemand es wagt, eine zu löschen.
Zwei kleinere Gewohnheiten zahlen sich aus. Setzen Sie einen Kommentar an den Anfang jeder Fixture-Gruppe, der sagt, wofür die Gruppe da ist und wann sie zuletzt geprüft wurde. Und halten Sie die Werte in der Fixture und nicht im Testcode, damit das Ändern eines Datensatzes kein Bearbeiten von Zusicherungen erfordert.
Welche Identitäts-Randfälle verdienen eine dauerhafte Fixture?
Eine kurze Liste deckt überraschend viel Risiko ab, weil jeder Eintrag eine andere Annahme bricht und nicht einen anderen Wert.
| Fixture | Die Annahme, die sie bricht |
|---|---|
| Eine über hundert Jahre alte Person | Dass Geburtsjahre immer in einer engen Spanne liegen |
| Ein Name, der viel länger ist, als die Oberfläche erlaubt | Dass eine Beispielbreite des Feldes repräsentativ ist |
| Eine Person ohne Familiennamen | Dass immer zwei Namensbestandteile existieren |
| Ein Name in nicht lateinischer Schrift oder mit diakritischen Zeichen | Dass das Alphabet immer das lateinische ist |
| Ein Datensatz mit fehlender optionaler Kennung | Dass jedes Feld immer gefüllt ist |
| Ein Geburtsdatum an einem Schalttag | Dass jedes Datum in jedem Jahr vorkommt |
| Ein Datensatz mit einem bewusst widersprüchlichen Paar | Dass die Konsistenzregeln noch durchgesetzt werden |
Der letzte Eintrag ist der, den Teams am häufigsten weglassen, und er ist der wertvollste. Er ist die einzige Fixture, die fehlschlägt, wenn eine Konsistenzregel versehentlich abgeschaltet wird, und Konsistenzregeln sind genau die Art Code, die während eines Vorfalls gelockert und nie wieder angezogen wird.
Wie verrotten Fixtures, und was hält das auf?
Eine Fixture wird nicht von allein falsch; das System um sie herum ändert sich. Eine Grenze wandert von einem Alter zu einem anderen und die Person, die gerade alt genug war, ist es nicht mehr. Eine Prüfregel wird strenger und ein Datensatz, der einst bestand, scheitert nun, was einen bestehenden Test aus einem Grund rot werden lässt, der nichts mit dem geprüften Code zu tun hat. Eine globale Formatumstellung landet und die halbe Fixture-Datei wird obsolet, ohne dass es jemand merkt.
Drei Gewohnheiten verlangsamen das. Datumsabhängige Fixtures sollten das Datum nennen, das sie annehmen, damit vergehende Zeit in der Datei sichtbar wird statt in einem roten Build entdeckt zu werden. Fixtures sollten regelmäßig durchlaufen, nicht nur wenn sich ihre Funktion ändert, damit Brüche früh auftauchen und nicht während einer unabhängigen Änderung. Und Durchsichten sollten fragen, ob jeder Datensatz seinen Platz noch verdient, denn die Kosten einer Fixture sind nicht ihre Anlage, sondern die Verwirrung, die sie stiftet, sobald ihr Zweck vergessen ist.
Der tiefere Punkt ist, dass Fixtures Daten mit einem Wartungsvertrag sind, und eine Suite, die sie als unveränderliche Geschichte behandelt, testet irgendwann das Produkt, wie es war, und nicht, wie es ist.
Sollten Fixtures überhaupt erzeugt werden?
Teilweise, und die Aufteilung sollte man bewusst treffen. Datensätze, die Verhalten festnageln, sollten ausgeschrieben sein, weil jemand sie ansehen und über sie nachdenken muss. Datensätze, die Menge liefern sollen — hundert Zeilen für einen Importtest, tausend für eine Migrationsprobe —, werden besser abgeleitet, weil niemand hundert Zeilen lesen kann und ihre genauen Werte nicht zählen, solange die Form stimmt.
Der Grund, Menge abzuleiten statt zu festschreiben, ist Wiederholbarkeit in großem Maßstab. Eine festgeschriebene Datei mit tausend Zeilen ist eine Wartungslast, die mit jeder Schemaänderung wächst, während ein abgeleiteter Stapel in dem Moment neu gebaut werden kann, in dem das Schema umzieht, und identisch neu gebaut wird, wenn ein fester Schlüssel ihn treibt. Datensätze aus dem Identitätsdatensatz-Erzeuger arbeiten in dieser Rolle: in sich stimmig je Land, aus einem Schlüssel wiederholbar und klar synthetisch, damit niemand eine Zeile für eine echte Kundin hält.
Für den kleinen handgeschriebenen Teil gilt das Umgekehrte. Halten Sie ihn winzig, halten Sie ihn lesbar, und binden Sie jeden Datensatz an ein benanntes Szenario, damit das Löschen eine informierte Entscheidung ist und keine Vermutung. Alles in beiden Hälften des Satzes ist für Softwaretests erfunden; nichts davon beschreibt eine echte Person, und nichts davon darf als Identität von jemandem dienen.
Für Entwickler: Den Fixture-Satz strukturieren
Behandeln Sie Fixture-Daten als Teil des Testcodes und legen Sie dieselben Maßstäbe an. Jeder Datensatz braucht einen Namen, der sein Szenario nennt, einen kurzen Kommentar, warum er existiert, und einen Platz in einer Gruppe, die klein genug ist, um sie in einem Zug zu lesen. Werte leben in Datendateien und nicht in Zusicherungen, damit ein Datensatz an einer Stelle aktualisiert werden kann.
Lassen Sie die Suite dann ihre eigenen Eingaben belegen. Führen Sie die Konsistenzprüfung gegen die Fixtures selbst aus, nicht nur gegen eingehende Daten, damit eine Fixture, die sich selbst widerspricht, laut scheitert statt still den toleranten Pfad zu testen. Geben Sie das aktuelle Datum als Eingabe, statt es zu lesen, damit eine Fixture mit einem Grenzdatum nicht über Nacht ihre Bedeutung ändert. Und halten Sie einen einzigen bewusst defekten Datensatz im Satz, dessen Ablehnung zugesichert ist, als dauerhaften Beleg dafür, dass die Wächter noch eingeschaltet sind.
Halten Sie schließlich die Herkunft fest. Ein einzeiliger Vermerk, dass diese Datensätze synthetisch und für Tests erzeugt sind, bewahrt die nächste Leserin vor der Annahme, sie kämen aus irgendeiner Datenbank — genau die Annahme, die dazu führt, dass eines Tages ein echter Datensatz in die Datei wandert, weil es gerade praktisch war.
Nächste Schritte
Öffnen Sie Ihre größte Fixture-Datei und versuchen Sie, die zehn Datensätze mit den nichtssagendsten Namen zu löschen; alles, was Sie nicht rechtfertigen können, ist ein Datensatz, den niemand versteht. Fügen Sie dann den bewusst widersprüchlichen Datensatz hinzu, falls er fehlt, sichern Sie zu, dass das System ihn ablehnt, und bestätigen Sie, dass die Suite rot wird, wenn diese Kontrolle abgeschaltet ist. Der Leitfaden zur Feldkonsistenz erklärt die Paarungen, die dieser Datensatz brechen soll, und ein frischer Stapel aus dem Identitätsdatensatz-Erzeuger deckt die Mengenhälfte des Satzes ab.