22    Testen mit JUnit 

»Es gibt keinen Grund, warum man einen Computer zu Hause haben sollte.«

– Ken Olson, Präsident der Digital Equipment Corp, 1977

 

22.1    Softwaretests 

Um möglichst viel Vertrauen in die eigene Codebasis zu bekommen, bieten sich Softwaretests an. Tests sind kleine Programme, die ohne Benutzerkontrolle automatisch über die Codebasis laufen und anhand von Regeln zeigen, dass vom Kunden gewünschte Teile sich so verhalten wie spezifiziert. (Die Abwesenheit von Fehlern kann eine Software natürlich nicht zeigen, aber immer zeigt ein Testfall, dass das Programm die Vorgaben aus der Spezifikation erfüllt.)

Obwohl Softwaretests extrem wichtig sind, sind sie unter Softwareentwicklern nicht unbedingt populär. Das liegt unter anderem daran, dass sie natürlich etwas Zeit kosten, die neben der tatsächlichen Entwicklung aufgewendet werden muss. Wenn dann die eigentliche Software geändert wird, müssen auch die Testfälle oftmals mit angefasst werden, sodass es gleich zwei Baustellen gibt. Und da Entwickler ein Feature eigentlich immer gestern fertigstellen sollten, fallen die Tests gerne unter den Tisch. Ein weiterer Grund ist, dass einige Entwickler sich für unfehlbare Kodierungsgötter halten, die jeden Programmcode (nach ein paar Stunden Debuggen) für absolut korrekt, performant und wohlduftend halten.

Wie lässt sich diese skeptische Gruppe nun überzeugen, doch Tests zu schreiben? Ein großer Vorteil von automatisierten Tests ist die Eigenschaft, dass bei großen Änderungen der Quellcodebasis (Refactoring) die Testfälle automatisch sagen, ob alles korrekt verändert wurde. Denn wenn nach dem Refactoring, etwa einer Performance-Optimierung, die Tests einen Fehler melden, ist wohl etwas kaputtoptimiert worden. Da Software einer permanenten Änderung unterliegt und nie fertig ist, sollte das Argument eigentlich schon ausreichen, denn wenn eine Software eine gewisse Größe erreicht hat, ist nicht absehbar, welche Auswirkungen Änderungen an der Quellcodebasis nach sich ziehen. Dazu kommt ein weiterer Grund, sich mit Tests zu beschäftigen: Es ist der positive Nebeneffekt, dass die erzeugte Software vom Design deutlich besser ist, denn testbare Software zu schreiben ist knifflig, führt aber fast zwangsläufig zu besserem Design. Und ein besseres Design ist immer erstrebenswert, denn es erhöht die Verständlichkeit und erleichtert die spätere Anpassung der Software.

 

22.1.1    Vorgehen beim Schreiben von Testfällen 

Die Fokussierung bei Softwaretests liegt auf zwei Attributen: automatisch, wiederholbar und nachvollziehbar. Dazu ist eine Bibliothek nötig, die zwei Dinge unterstützen muss:

• Testfälle sehen immer gleich aus und bestehen aus drei Schritten. Zunächst wird ein Szenario aufgebaut, dann wird die zu testende Methode oder Methodenkombination aufgerufen, und zum Schluss wird mit der spezifischen API des Test-Frameworks geschaut, ob das ausgeführte Programm genau das gewünschte Verhalten gebracht hat. Das übernehmen eine Art »Stimmt-es,-dass«-Methoden, die den gewünschten Zustand mit dem tatsächlichen abgleichen und bei einem Konflikt eine Ausnahme auslösen. Im Fehlerfall sollen die Tests genau dokumentieren, was schiefgelaufen ist.

• Das Test-Framework muss die Tests laufen lassen und im Fehlerfall eine Meldung ausgeben. Dieser Teil nennt sich Test-Runner.

Wir werden uns im Folgenden auf sogenannte Unit-Tests beschränken. Das sind Tests, die einzelne Bausteine (engl. units) testen. Daneben gibt es andere Tests, wie Lasttests, Performance-Tests oder Integrationstests, die aber im Folgenden keine große Rolle spielen.