Es ist jetzt etwas mehr elf Jahre her, da habe ich in einem Projekt für das damalige Internet Startup Censio meinen ersten Unit Test geschrieben. Kent Beck hatte gerade sein eXtreme Programming Buch veröffentlich und gemeinsam mit Erich Gamma in den Schweizer Bergen JUnit programmiert. Das Projekt bei Censio war stressig, der Internet Boom war auf seinem Höhepunkt und das ganze Entwickler Team arbeitete praktisch rund um die Uhr. Durch den Stress schlichen sich bei mir viele Fehler ein und JUnit erschien mir eine Möglichkeit dieses Problem in den Griff zu bekommen und so war es auch! Seit dem bin ich Unit Test infiziert und habe keinen Code mehr ohne Unit Tests geschrieben.
Trotzdem sehe ich noch viele Projekte die Code ohne Tests entwickeln. Das ist für mich nicht nachvollziehbar und deshalb möchte ich mit diesem Blog eine Serie starten, die zeigen soll warum Unit Tests so nützlich sind und wie man als Entwickler richtig testet.
Mich erinnerte das ein wenig an die neue „Gib Aids keine Chance“ Kampagne: Mach’s mit. Auch meine Message an alle Entwickler: Mach’s mit Unit Tests!
Was sind Unit Tests?
Unit Tests werden auch Modultests genannt, weil sie ein konkretes Software Modul auf Programmierfehler überprüfen. Typischerweise testet ein Unit Test eine Klasse oder eine Schnittstelle. Die Module werde dabei isoliert von einander getestet, d.h. ohne die Interaktion/Integration mit anderen Modulen. Dadurch werden die Tests sehr robust und können schnell ausgeführt werden. Ein fehlgeschlagener Test bedeutet zudem, dass ein Fehler in dem getesteten Modul gefunden wurde – als Entwickler muss man daher nicht lange nach dem fehlerhaften Code suchen.
Warum Unit Tests?
Unit Tests sind ein wichtiger Bestandteil für agile (und nicht agile) Software Entwicklung:
- Kurze Entwicklungszyklen mit lauffähiger Software am Ende sind fester Bestandteil jeder agilen Methode. Nur wenn der Code automatisiert getestet wird, ist er robust genug, damit nachfolgende Iteration darauf aufbauen können. Ohne diese Tests wird die Entwicklungsgeschwindigkeit sinken und das Team wird sich mehr mit Bugfixing beschäftigen als mit neuen Funktionen.
- Ohne Unit Tests funktioniert kein Continuous Integration!
- Ohne Unit Tests kann man kein Refactoring machen!
- Ohne Unit Tests funktioniert Collective Code Ownership nicht!
- Ohne Unit Tests ist ein emergentes Design schwierig – gerade ein Test First Ansatz führt zu besserem Design und besserem Code.
- Unit Tests sind zudem die beste Dokumentation die ich kenne. Neue Teammitglieder können somit schneller und einfacher eingearbeitet werden. Andere Teammitglieder haben es einfach den Vertrag (contract) einer Klasse oder eines Service zu verstehen.
Vorurteile gegenüber Unit Tests
Trotzdem: Immer noch gibt es viele Projekte ohne Unit Tests oder ohne funktionierende Unit Tests (maven.test.skip=true ist ein weit verbreiteter Parameter und der Beweis dafür). Die Argumente sind immer gleich:
- Keine Zeit für Unit Tests.
- Kein Budget für Unit Tests.
- Der Kunde wollte keine Unit Tests bzw. hat diese nicht eingefordert.
- Unit Tests würden für die Anwendung oder die eingesetzten Technologien nicht funktionieren.
- Man würde die Unit Test erst am Ende des Projekts schreiben.
- …
Fehlendes Knowhow
Meine Erfahrung ist, dass diese Argumente nur vorgeschoben sind. Der wahre Grund ist, dass das Team nicht weiß wie man seinen Code richtig testet. Denn auch wenn die Frameworks wie JUnit oder TestNG einfach aussehen, so ist Unit testen alles andere als einfach. Testgetriebene Entwicklung (TDD) ist noch schwieriger – es ist eine ganz andere Philosophie Anwendungen zu entwickeln. Man muss dazu wissen, wie man Testfälle konzipiert, Testdaten erstellt und verwaltet, Mock Objekte erzeugt, Testabdeckung misst, Testfälle refactored und mit verschiedensten Technologien und Frameworks wie Java EE oder Spring beim Testen umgeht. Oft wird man mehr Testcode erzeugen als funktionalen Code und doch gibt es nur selten Konventionen für Testcode und noch weniger Test Design Patterns.
Deshalb werde ich an Hand eines konkreten Beispiels Schritt für Schritt in einzelnen Blog Einträgen zeigen, wie man aus meiner Sicht richtig Unit testet und dabei unterschiedliche Frameworks, Konventionen und Test Design Patterns vorstellen. Hoffe auf viel Feedback von meinen Kollegen, sowie Unit Test Freunden und Gegnern, so dass am Ende viel mehr Entwickler sagen werden: Ich mach’s mit…Unit Tests!
Teil 1: JUnit – Der erster Testfall
War dieser Beitrag hilfreich?
Weitere Beiträge
von Mirko Novakovic
21.2.2014 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Mirko Novakovic
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.