Die Auswahl der Länder für Testdaten gilt in vielen Teams als lästige Pflicht nach der eigentlichen Arbeit. Jemand öffnet die Liste aller Länder, die das System kennt, setzt Häkchen bei einigen vertrauten Namen und wendet sich wieder Wichtigerem zu. Die Entscheidung gerinnt anschließend zu einem Fixture, und dieses Fixture bestimmt still, was die Testsuite finden kann und was nicht.
Dieser Beitrag betrachtet die Entscheidung selbst. Er beschreibt drei Achsen für die Zusammensetzung des Sets, erklärt, warum ein gutes Set bewusst unbequeme Einträge braucht und nicht nur populäre, und zeigt, wie das Set unter Versionskontrolle bleibt, damit ein Ergebnis von letztem Monat auch heute noch etwas bedeutet.
Warum verdient das Länder-Set eine eigene Entscheidung?
Aus einem einzelnen Fixture folgt nur, dass ein Datensatz durchläuft. Ein Länder-Set belegt dagegen, dass die Regeln dort greifen, wo sie hingehören. Das sind zwei verschiedene Aussagen, und nur die zweite schlägt fehl, wenn eine Regel an die falsche Region gebunden ist.
Man betrachte eine Regel, die eine Postleitzahl als erforderlich und rein numerisch annimmt. Ein Datensatz aus einem Land, das diese Annahme erfüllt, belegt, dass die Regel läuft. Über die Länder, in denen die Annahme falsch ist, sagt er nichts, und der Fehler zeigt sich später im Produktivbetrieb statt in der Suite. Das Set ist das Instrument, das diese Klasse von Lücken sichtbar macht, und verdient deshalb dieselbe Prüfung wie das Schema, das es ausübt.
Zugleich ist das Set die günstigste Dokumentation, die ein Team hinterlassen kann. Wer die Liste liest, erkennt, welche Konventionen die Suite zu kennen behauptet und welche sie stillschweigend ignoriert.
Drei Achsen: Erreichbarkeit, Datenschwierigkeit, Grenzwert
Die meisten Diskussionen über eine Länderliste sind in Wahrheit Diskussionen darüber, welche Achse zählt. Sie getrennt zu benennen, ist schon der größte Teil der Arbeit.
| Achse | Die Frage dahinter | Was sie sichtbar macht |
|---|---|---|
| Geschäftliche Erreichbarkeit | Können wir dieses Land überhaupt bedienen? | Zahlungs-, Liefer-, Abrechnungs- und Sprachzweige, die nie ausgeführt werden |
| Datenschwierigkeit | Wie unbequem sind die Daten selbst? | Zeichensätze, Schreibrichtung, Feldlänge und Annahmen beim Auswerten |
| Grenzwert | Wird eine Grenze bis zum Rand ausgereizt? | Abschneiden, Layout-Überlauf und Fehler um eins |
Ein Set, das nur der ersten Achse folgt, ist eine Liste von Märkten. Das ist ein brauchbarer Anfang und ein schwaches Ergebnis, denn die unbequemen Fälle sammeln sich genau dort, wo kein Umsatz sie rechtfertigt.
Was macht ein gutes Grenzwert-Beispiel aus?
Ein Grenzwert-Beispiel verdient seinen Platz, weil es für ein bestimmtes Feld der längste, der kleinste oder der am wenigsten kooperative Fall ist. Der Ländername, der in die schmalste Spalte passen muss, der Bezirksname, der auf ein gedrucktes Etikett passt, die Adresszeile, die in ein festes Feld eingepasst wird – nichts davon ist eine Kuriosität. Es sind die Eingaben, die eine feste Breite offenlegen.
Die nützliche Gewohnheit besteht darin, jede Grenze mit der Zusicherung zu paaren, die sie brechen soll. Ist ein Feld für eine bequeme Adresse bemessen und enthält das Set eine alles andere als bequeme Adresse, hat der Eintrag einen Grund zu existieren. Sind alle Einträge angenehm kurz, bleibt das Layout ungeprüft, unabhängig von der Anzahl der Einträge.
Breite und Tiefe ersetzen einander nicht. Zwanzig ähnliche Länder durchlaufen zwanzig Mal denselben Codepfad; drei gut gewählte Extreme durchlaufen drei verschiedene.
Wie geht man mit Ländern um, in denen ein Feld nicht gilt?
Einige Länder kennen überhaupt kein Postleitzahlensystem, und einige haben keine Gliederungsebene, die zu dem Feld passt, auf dem ein Formular besteht. Das sind keine fehlenden Daten. Es ist die Form der Daten, und ein Set, das solche Länder auslässt, erzeugt eine Suite, die eine korrekte Adresse als ungültig behandelt.
Die Unterscheidung, die es festzuhalten gilt, ist jene zwischen einem Wert, der fehlt, weil das Feld nicht anwendbar ist, und einem Wert, der fehlt, weil ihn niemand geliefert hat. Nur der zweite Fall ist ein Defekt. Macht ein Formular ein solches Feld überall erforderlich, ist das Länder-Set das Einzige, was das offenlegt: Der fehlerhafte Fall lässt sich nicht einmal schreiben, ohne ein Land zu nennen, in dem das Feld tatsächlich nicht existiert.
Wo ein anderer Beitrag die länderspezifische Form eines Feldes bereits behandelt, bleibt dieser hier schmal und übergibt die Leserschaft. Der Leitfaden zu den Postleitzahlenformaten nach Land ist die richtige Adresse für die Frage, wie ein Code aussieht; hier geht es nur darum, ob das Set einen Eintrag enthält, für den diese Frage bedeutungslos ist.
Woraus besteht ein Standardset üblicherweise?
Ein Set, das den Kontakt mit einem echten Team übersteht, pendelt sich meist auf drei Gruppen ein, und jede Gruppe leistet Arbeit, die die anderen nicht leisten können.
- Das Heimatland oder der Ort, an dem die meisten Annahmen des Teams entstanden sind. Es ist die Bezugsgröße, neben der alles andere fremd wirkt.
- Die wichtigsten Märkte, ausgewählt nach den Zweigen, die sie ausüben: Lieferung, Zahlung, Abrechnung und Inhalte.
- Eine kleine Zahl von Extremen, ausgewählt, weil sie eine Grenze brechen, und nicht, weil dort jemand ausliefert.
Die dritte Gruppe fällt zuerst weg, wenn eine Suite aus Geschwindigkeitsgründen gekürzt wird, und sie sollte zuletzt gestrichen werden. Eine Suite, die schnell läuft und jeden Abschneidefehler übersieht, ist nicht schnell, sondern blind.
Für Entwickler: das Set als versioniertes Asset behandeln
Die praktische Empfehlung lautet, die Länderliste nicht länger als Konfiguration zu behandeln, sondern als ein Asset mit eigener Identität.
Geben Sie dem Set einen Namen und eine Version und legen Sie diese Kennung neben die Fixtures, die davon abhängen. Ändert sich das Set, ändert sich auch die Bedeutung jeder Zusicherung, die dagegen geschrieben wurde, und ohne Kennung lässt sich eine Regression nicht von einer Neudefinition unterscheiden. Ein gespeichertes Ergebnis bleibt nur dann interpretierbar, wenn das Set rekonstruierbar ist, gegen das es lief.
Halten Sie die Begründung im Repository neben der Liste. Notieren Sie zu jedem Eintrag, für welche Achse er gewählt wurde und welche Zusicherung er stützen soll, damit die nächste Person, die die Liste ausdünnt, weiß, was sie entfernt.
Befüllen Sie das Set mit konstruierten Werten. Fixtures sollten niemals die Angaben einer echten Person tragen, und ein Set aus echten Datensätzen ist zugleich ein Datenschutzproblem und ein Reproduzierbarkeitsproblem. Das Länder- und Regionenverzeichnis ist ein guter Ort, um vor dem Eintragen zu prüfen, wie ein Land und eine Region beschrieben werden, und eine einzelne Länderseite wie der Eintrag zu den Vereinigten Staaten zeigt, wie die Notizen zu einem Land aussehen, wenn sie an einer Stelle zusammenlaufen.
Ein Hinweis deckt alles oben Gesagte ab. Die Länderlisten, Regionsnamen und Beispielwerte in diesem Beitrag sind synthetische Beispiele, die eine Entscheidung beim Testen von Software veranschaulichen. Sie beschreiben keine reale Organisation, keinen realen Datensatz und keine reale Person und taugen nicht als Beleg für irgendetwas außerhalb einer Testumgebung.
Nächste Schritte
Nehmen Sie das Fixture-Set, das Sie heute verwenden, und markieren Sie jeden Eintrag mit der Achse, für die er gewählt wurde. Einträge ohne Achse sind Kandidaten für die Entfernung, und Achsen ohne Eintrag sind die Lücken, die zuerst zu füllen sind. Notieren Sie anschließend zu jedem Eintrag die Zusicherung, die er schützt. Der Leitfaden zur Abdeckung der Länderdaten macht aus dieser Liste etwas Prüfbares, und der Leitfaden zur Aktualität der Länderdaten behandelt den Fall, dass ein Eintrag nicht mehr stimmt.