Schneide Blog

Im Jahr 2002 entwickelten wir Software für eine Messapparatur, die unter anderem mit einer historisch wertvollen Datenbank über eine VT3270-Terminalemulation kommunizieren musste. Der Datenaustausch geschah über kleine Textdateien, die ausgelesen oder geschrieben wurden. Das Format der Textdateien war strikt spezifiziert und auf ein Minimum reduziert. Einige Messwerte mussten im “wissenschaftlichen Format” übergeben werden:
1.32E-01 ist gleichwertig zu 0.132

Wichtig an der Spezifikation war, dass das Format nach dem Exponententrenner “E” immer ein Vorzeichen haben musste, d.h. es wurde für den Wert 132 nicht 1.32E02, sondern 1.32E+02 erwartet.

Dummerweise hatte das damals verwendete Java 1.4.0 genau an dieser Stelle einen Bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4691683
Das Format +0.00000E00 erzeugt Wertrepräsentationen wie “+1.32E+02”, aber auch solche Kuriositäten wie “+1.32E-+01”.

Interessant ist dabei, dass das Vorzeichen des Formats im Exponenten wiederholt wird. Manuelles Entfernen der überflüssigen “+”-Zeichen brachte damals das gewünschte Ergebnis in die Dateien.

Dummerweise war das nicht der einzige Bug in Hinsicht auf das wissenschaftliche Formatieren in Suns DecimalFormat, so dass mit der Version Java 1.5 das Format “+0.00000E00” Wertrepräsentationen wie “+1.32E02”, aber auch Kuriositäten wie “+-1.32E02” erzeugt.

Mit der Änderung der Java-Version kam also ein vor Jahren durch Workaround behobener Fehler zurück, da jetzt (unter anderem) der Workaround zum Fehler wurde.

Was habe ich aus dieser Episode gelernt? Liefere möglichst kein spezifiziertes Format aus, das nicht mit Unit Tests vollständig abgesichert wurde. Und vor allem: Sichere jeden Bugreport, der nach außen geht, mit einem entsprechenden Test ab. Denn wenn der Bug nicht mehr da ist, wird auch der Workaround hinfällig und im schlimmsten Fall sogar selbst zum Bug.

Nehmen wir an, wir hätten eine Klasse FileProvider, die mittels der Methoden getFile() File-Instanzen zurückgibt, deren Pfad bestimmte Eigenschaften erfüllen muss. Im folgenden Test prüfen wir eine dieser Eigenschaften ab:


public void testFilePath() {
FileProvider fileProvider = new FileProvider();
assertEquals("path/myfile.txt", fileProvider.getFile());
}


Wenn jetzt der verwendete FileProvider im einfachsten Fall wie folgt implementiert ist:


class FileProvider {
public File getFile() {
return new File("path/myfile.txt");
}
}


schlägt der Test trotzdem fehl:

junit.framework.AssertionFailedError: expected:<path/myfile.txt> but was:<path/myfile.txt>

und man verbringt eine harte Zeit, sich klarzumachen, was gerade wirklich passiert ist.

Die Lösung liegt in der verwendeten assertEquals-Methode und der Implementierung der toString()-Methode im File-Typ. Anstatt, wie eigentlich vorgesehen, zwei String-Objekte zu vergleichen, werden mit der obigen assertEquals-Methode zwei Objects, konkret ein String als Soll-Instanz und ein File als Ist-Instanz, miteinander verglichen. Dieser Vergleich geht schon wegen der verschiedenen Instanztypen schief. Die Ausgabe basiert allerdings auf dem Ergebnis, das die jeweilige toString()-Methode zurückgibt. Und da geben beide Instanzen die gleiche Zeichenkette zurück, was zu der obigen, sehr mißverständlichen Fehlermeldung führt.

Ich hätte dazu zwei Verbesserungsvorschläge:

• Die Fehlermeldung so umbauen, dass sie die verschiedenen Typen der Objekte zeigt, wenn die Gleichheitsprüfung am Typ der Objekte gescheitert ist (das könnte mit der gegenwärtigen Struktur der equals()-Methoden etwas schwieriger werden) und nur dann auf die Darstellung der Instanzwerte (über toString()) zurückgreift, wenn die Prüfung daran scheiterte.
• Eine zusätzliche Methode definieren, die ebenfalls eine textuelle Objektrepräsentation zurückgibt und, falls sie vorhanden ist, von JUnit anstelle von toString() aufgerufen wird. Also eine toJUnitString() oder so ähnlich. Ist sie nicht definiert, wird weiterhin toString() verwendet. Im meinem Fall hätte dieser Vorschlag also nichts geholfen.

Was wären weitere Möglichkeiten?