Nachträglicher Einsatz von JUnit zum Testen von älterem Code

Test Driven Design ist eine prima Idee: Für jeden neuen Codeblock schreibt man einen oder mehrere Tests – oder sogar noch dogmatischer: erst den Test, dann den Code. Frameworks können sich um das Durchführen der Tests kümmern, und mit entsprechender Integration in den Build-Prozess kann man den Code zeitgleich testen. Falls man eine Anwendung von Grund auf neu entwickelt, sind integrierte Tests sicher das Beste.

Aber leider ist das nicht immer der Fall. Wenn man sich einem vorhandenen Source-Tree gegenübersieht, kann die Vorstellung, für all die Komponenten Tests zu entwickeln, schon ziemlich entmutigend sein. Ein praktikabler Ansatz besteht darin, die Schwelle für Tests niedriger anzulegen, indem man zuerst ein Test-Framework einrichtet und dann Tests für bestehenden Code entwickelt.

JUnit ist ein Unit Testing-Framework. Unit Testing wird der Prozess genannt, bei dem man jede Einheit (unit) des Systems unabhängig testet, anstatt den gesamten Code als „Komplett“-System zu testen. In Java ist die Standard-Einheit die Klasse. Wenn man eine Klasse namens Thing hat:

dann wäre ThingTest eine Klasse zum Testen von Thing. Der Kern von JUnit ist die Klasse TestCase, welche man erweitert, um seine eigenen Tests zu erstellen. ThingTest würde also TestCase erweitern.