Feldkonsistenz bei Identitätsdaten ist die Eigenschaft, die eine Menge erzeugter Werte überhaupt brauchbar macht. Jedes Feld eines Datensatzes kann für sich plausibel sein, während der Datensatz als Ganzes etwas Unmögliches beschreibt — eine Straße in einem Land, eine Postleitzahl aus einem anderen, eine Telefonnummer aus einem dritten — und genau in diesem Zustand hört das Testen auf, die Wahrheit zu sagen.
Dieser Artikel erklärt, wie widersprüchliche Datensätze entstehen, warum sie Tests bestehen lassen, die scheitern müssten, und was nötig ist, damit ein Testdatensatz beim Wachsen stimmig bleibt.
Warum ergeben einzeln korrekte Felder einen falschen Datensatz?
Der Zufall ist der übliche Täter, und es ist kontraintuitiv, wie schnell er Unsinn erzeugt. Ziehen Sie ein Land, dann unabhängig davon eine Stadt, und das Paar wird mit einer Wahrscheinlichkeit nahe eins nicht zusammenpassen. Jeder Wert stammt aus dem richtigen Vorrat; nichts ist fehlerhaft geformt; die Kombination kommt einfach nie vor.
Von Hand gebaute Datensätze scheitern anders, aber nicht seltener. Wer sie schreibt, arbeitet meist Feld für Feld, prüft jeden Wert gegen das eigene Wissen und hat keinen Grund, Land, Verwaltungsgliederung, Postleitzahl und Telefonvorwahl gleichzeitig im Kopf zu behalten. Das Ergebnis ist ein Datensatz, der sorgfältig aussieht und in sich widersprüchlich ist.
Es gibt eine dritte Quelle, leiser als beide: Datensätze, die aus mehreren Quellen zusammengesetzt sind. Eine Staging-Zeile nimmt ihren Namen vielleicht aus einem Startwert, ihre Adresse aus einer Fixture und ihre Kontaktdaten aus dem, was die Testautorin gerade offen hatte. Jeder Teil war dort, wo er herkam, in Ordnung.
Wo Widerspruch zu einem falschen Bestehen wird
Denken Sie an eine Regel, nach der eine Kundin ein Mindestalter haben muss, um ein Produkt zu kaufen, und an einen Test, der prüft, ob die Regel funktioniert. Mit einem Geburtsdatum in einem Jahrhundert und einem gespeicherten Alter aus einem anderen durchläuft der Test womöglich den Annahmezweig, obwohl der geprüfte Datensatz hätte abgelehnt werden müssen — und nichts meldet ein Problem, weil keine Kontrolle fehlgeschlagen ist.
| Widersprüchliches Paar | Was es verbirgt |
|---|---|
| Land und Form der Postleitzahl | Die gesamte Postleitzahlenprüfung, weil die Nummer weiterhin wohlgeformt ist |
| Land und Telefonvorwahl | Sprachraum- und Routinglogik, die still auf einen Standard zurückfällt |
| Geburtsdatum und Altersgrenze | Altersschranken, sodass ein bestehender Test nur belegt, dass der Annahmepfad läuft |
| Adresse und Kennungsformat | Die Kennungsprüfung, die bei mehrdeutigem Land übersprungen wird |
| Verwaltungsgliederung und Postleitzahlenbereich | Die Adressnormalisierung, weil auf einen Widerspruch keine Regel anwendbar ist |
Das Muster ist in jeder Zeile dasselbe: Der Widerspruch entfernt die Eingabe, die den Fehler ausgelöst hätte. Eine Testsuite voller solcher Datensätze ist nicht schwach, weil ihr Zusicherungen fehlen; sie ist schwach, weil ihre Eingaben nie die Zweige erreichen, in denen die Zusicherungen leben.
Sollten widersprüchliche Daten abgelehnt oder repariert werden?
Das hängt davon ab, wer sie hält, und hier etwas falsch zu machen, richtet eigenen Schaden an. Eingehende Daten von einer Person sollten repariert werden, wo die Absicht eindeutig ist, und nachgefragt werden, wo sie es nicht ist, denn ein Mensch wartet. Erzeugte Daten und Fixture-Daten sollten rundheraus abgelehnt werden, weil es keine Absicht zu bergen gibt und ein reparierter Datensatz den Defekt in dem verbirgt, was ihn erzeugt hat.
Die Faustregel für einen Erzeuger lautet, dass Widerspruch ein Fehler im Erzeuger ist und keine Eigenschaft, die man nachgelagert duldet. Alles andere erzieht das Team dazu, toleranten Code zu schreiben, der später auf echte Eingaben trifft und sie verschluckt.
Für die Prüfung im Produkt ist die nützliche Frage, was eine gescheiterte Konsistenzprüfung mit dem Datensatz tun soll. Eine fehlende Postleitzahl ist eine Erfassungslücke, die die Nutzerin beheben kann. Eine Postleitzahl, die existiert, aber zu einer anderen Region gehört, ist ein Widerspruch, den kein erneuter Versuch der Nutzerin auflöst, ohne dass sich auch die Region ändert. Diese beiden verdienen eine unterschiedliche Behandlung.
Wie streng sollte eine Konsistenzregel sein?
Machen Sie sie so schwach, wie sie sein kann, und fangen Sie dennoch die Fehler ab, die zählen, und sagen Sie ausdrücklich, welche Stärke sie hat. Regeln kommen in drei Stärken, und sie ohne Kennzeichnung zu mischen, ist der Weg, auf dem eine Codebasis Prüfungen bekommt, die niemand erklären kann.
- Eine Warnung hält den Widerspruch fest und lässt den Datensatz durch, was für abgeleitete und nicht für erklärte Beziehungen richtig ist.
- Eine Ablehnung blockiert den Datensatz, was richtig ist, wenn der Widerspruch unmöglich und nicht bloß ungewöhnlich ist.
- Eine Reparatur schreibt einen Wert um, damit er zu einem anderen passt, was die gefährlichste der drei ist und nur dort verwendet werden sollte, wo die Rangfolge dokumentiert ist.
Der meiste Wirrwarr in diesem Bereich entsteht daraus, eine statistische Korrelation als harte Regel zu behandeln. Eine Telefonvorwahl deutet meist auf ein Land hin, aber nicht immer; eine Postleitzahl deutet meist auf eine Region hin, doch Grenzgebiete und Ausnahmen existieren. Eine Neigung als Verbot zu kodieren, weist echte Menschen ab, und zwar am häufigsten jene, die den Annahmen in den Daten am wenigsten entsprechen.
Müssen erzeugte Datensätze über den ganzen Stapel stimmig sein?
Innerhalb eines Datensatzes ja. Über einen Stapel hinweg nein — und beide zu verwechseln, verschwendet in der einen Richtung Mühe und erzeugt in der anderen Defekte. Ein Stapel von tausend Datensätzen sollte Vielfalt enthalten: verschiedene Regionen, verschiedene Namensformen, verschiedene Altersgruppen, einige Datensätze mit fehlenden Feldern. Er sollte nicht tausend Datensätze enthalten, die jeder dieselbe Person zu sein behaupten.
Es gibt einen praktischen Grund, Stapel innerlich vielfältig zu halten. Ein Test, der gegen hundert nahezu identische Datensätze läuft, durchläuft einen Codepfad hundertmal und meldet Erfolg. Derselbe Test gegen hundert verschiedene Datensätze durchläuft die Zweige, die zählen — genau das, was eine Last- oder Migrationsprobe eigentlich feststellen will.
Wo ein Stapel Einheitlichkeit braucht, ist es die Wiederholbarkeit: Dieselbe Eingabe sollte denselben Stapel erzeugen, damit ein einmal gefundener Fehler wieder gefunden werden kann. Erzeugte Datensätze aus dem Identitätsdatensatz-Erzeuger behalten diese Eigenschaft, weil sie alles aus einem Identitätsschlüssel ableiten; das lässt einen Stapel zugleich vielfältig und wiederholbar sein. Die Werte bleiben synthetische Datensätze für Softwaretests, nicht Details echter Menschen.
Welche Paarungen brechen in der Praxis am häufigsten?
Vier Paarungen verursachen die Mehrheit der Defekte. Das Land mit dem Adressblock steht an erster Stelle, weil Adressformen der offensichtlichste nationale Teil eines Datensatzes sind. Das Land mit der Telefonvorwahl steht an zweiter Stelle, weil Vorwahlen kurz und leicht unverknüpft zu lassen sind. Das Geburtsdatum mit der Altersschranke steht an dritter Stelle, weil die Schranke meist als Zahl ausgedrückt wird und nicht als Vergleich. Das Land mit der Identifikationsnummer steht an vierter Stelle, weil eine bloß ziffernförmige Nummer überall durch eine schwache Kontrolle rutscht.
Jede davon hat einen billigen Test: Erzeugen Sie einen Datensatz, ändern Sie ein Mitglied des Paares von Hand und bestätigen Sie, dass das System es bemerkt. Tut es das nicht, wurde das Paar nie wirklich geprüft, und der Datensatz, der hätte scheitern müssen, bestand die ganze Zeit.
Für Entwickler: Wo die Regeln durchgesetzt werden
Erzeugen Sie in Abhängigkeitsreihenfolge und prüfen Sie in derselben Reihenfolge. Zuerst das Land, dann die Gliederung, die dazu gehört, dann alles, was sich aus diesen beiden ableitet — Adresse, Postleitzahl, Telefonvorwahl, Kennungsformat, Währung und Sprachraum. Ein Erzeuger, der Felder in der Reihenfolge zieht, in der das Formular sie anzeigt, wird Widersprüche produzieren, denn die Reihenfolge des Formulars betrifft die Darstellung und die Reihenfolge der Daten die Kausalität.
Legen Sie die feldübergreifende Prüfung an eine Stelle, statt sie über Formular, API und Datenbank zu verstreuen. Doppelte Regeln driften auseinander, und die abweichende ist immer die, die niemand liest. Modellieren Sie jede Paarung ausdrücklich, damit eine Prüferin sieht, welcher Wert welchen einschränkt, und geben Sie jeder Regel ein Kennzeichen ihrer Stärke, damit ein späterer Leser weiß, ob sie blockiert oder nur warnt.
Nehmen Sie in Fixtures einen bewusst widersprüchlichen Datensatz neben die gültigen auf — dieselbe Person mit genau einer gebrochenen Paarung — und sichern Sie zu, dass das System ihn ablehnt. Dieser eine Fall ist die wertvollste Fixture im Satz, weil er als einziger belegt, dass die Konsistenzregeln noch eingeschaltet sind. Auch das alles sind synthetische Daten für Tests: keine Beschreibung einer echten Person, und sie dürfen nicht an deren Stelle treten.
Nächste Schritte
Schreiben Sie die fünf Feldpaarungen auf, auf die sich Ihr Produkt verlässt, und prüfen Sie jede im Code; wird eine Paarung nirgends durchgesetzt, wird sie angenommen statt geprüft. Holen Sie dann aus dem Identitätsdatensatz-Erzeuger einen Stapel erzeugter Datensätze und lassen Sie ihn durch einen Migrations- oder Importpfad laufen, und achten Sie auf Zeilen, die aus dem falschen Grund gelingen. Der Artikel über Test-Fixtures erklärt, wie Sie einen defekten Datensatz dauerhaft in der Suite halten, damit diese Eigenschaft nie zurückfällt.