Apropos Testdaten: Manchmal ist es wesentlich einfacher, über konkrete Beispiele zu reden, als lange Spezifikationen zu schreiben.

Hier ist ein Auszug aus der Test-Suite für das Analysieren (parsing) von Datumswerten, in Python:

("2003-09-25", datetime(2003, 9, 25), "date with dash"),
("09-25-2003", datetime(2003, 9, 25), "date with dash"),
("25-09-2003", datetime(2003, 9, 25), "date with dash"),
("10-09-2003", datetime(2003, 10, 9), "date with dash"),

Zur Erläuterung: pro Zeile ist ein Beispiel aufgeführt, mit Eingabe ("2003-09-25") und der erwarteten Ausgabe, etwa datetime(2003, 9, 25), mit Jahr, Monat, Tag, also 25. September 2003. Am Ende steht eine Erklärung zum jeweiligen Beispiel.

Ein Eingabe-Wert wie "10-09-2003" ist mehrdeutig: soll es der 10.9. oder der 9.10. sein? Das Beispiel in der letzten Zeile legt fest: es soll der 9. Oktober sein (datetime(2003, 10, 9)), es wird also das Format Monat-Tag-Jahr angenommen.

Die Beispiele davor zeigen, dass der Code etwas smarter ist: "25-09-2003" und "09-25-2003" werden beide als 25. September 2003 interpretiert. Wenn also Monat-Tag-Jahr offensichtlich nicht geht, wird Tag-Monat-Jahr genommen.

Noch mehrdeutiger wird’s in diesem Beispiel:

("10-09-03", datetime(2003, 10, 9), "date with dash"),

Aha, es soll 2003 sein, also das Jahr steht am Ende (Monat-Tag-Jahr)– außer, wenn das Jahr vierstellig ist, wie im ersten Beispiel oben "2003-09-25".

Können Sie sich vorstellen, wieviel mehr Arbeit und geistige Klimmzüge es kostet, solche Regeln als in sich widerspruchsfreie, lückenlose und möglichst redundanzfreie Spezifikation zu schreiben? Wo immer es geht, sollte man also ausführliche Spezifikationen durch eine Sammlung von Beispielen ersetzen, die ggf. von Nutzern und Entwicklern gemeinsam festgelegt werden. Etwaige Widersprüche und Spezialfälle kann man dann immer noch behandeln, sobald sie sichtbar werden. Eine Suite von automatisierten Tests sichert auf jeden Fall, dass alle alten Beispiele auch weiterhin funktionieren.

Matthias Berth