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

Zwar wird einem immer wieder wärmstens ans Herz gelegt, seine Tests gleichzeitig mit dem Code zu schreiben - oder besser sogar noch davor -, aber jeder Entwickler verfügt bestimmt noch über eine Menge Code ohne Tests. Der folgende Artikel beschreibt, wie man vorhandene Anwendungen um Tests ergänzt.

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.


Themenseiten: Anwendungsentwicklung, Software

Fanden Sie diesen Artikel nützlich?
Content Loading ...
Whitepaper

Artikel empfehlen:

Neueste Kommentare 

Noch keine Kommentare zu Nachträglicher Einsatz von JUnit zum Testen von älterem Code

Kommentar hinzufügen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *