Die bisherigen Teile Episode 1, Episode 2 und Episode 2 und Episode 3 über die Vorgehensweisen bei Softwareprojekten starteten mit der Episode 3 über die Vorgehensweisen bei Softwareprojekten starteten mit der Vorgeschichte, heute geht es ums Testen, insbesondere um Unit Tests. Ein paar Wochen später fand Hans im Netz diverse Testvorgehen und Tools. „Fred schau dir das mal an, die Unit Tehref="http://miradlo.net/bloggt/index.php?69-s"">Vorgeschichte, heute geht es ums Testen, insbesondere um Unit Tests. Ein paar Wochen später fand Hans im Netz diverse Testvorgehen und Tools. „Fred schau dir das mal an, die Unit Tests sind wirklich cool!“ Er war auf der Seite JUnit und beide studierten die Beschreibung. „Das ist aber verflixt aufwändig umzusetzen. Wir müssten mindestens ein Personenjahr aufwenden, um unser System damit auf Funktion zu überprüfen“, bemerkte Karl. Orlando kam um die Ecke und klärte die Beiden auf: „Wir müssen ja nicht alles auf einmal testen. Wir bauen die Testfälle für neue Funktionalität. Wenn wir unser wöchentliches Refactoring durchführen können wir die wichtigsten Testfälle für den bestehenden Code erstellen. Auf diese Weise werden die dunklen Stellen im System weniger und wir können ruhiger schlafen.“ Dies erschien den Kollegen eine gute und einfache Vorgehensweise zu sein.

Beim Unit Test sollten (mindestens) die folgenden Dinge beachtet werden:

• Unit Test bedeutet wirklich Unit. Teste vor allem einzelne Komponenten und keine komplexen Abläufe mit Unit Test. Für komplexe Abläufe und Interaktionen mit mehreren Klassen bietet sich z.B. ein ANT Script eher an.
• Teste die Übergabeparameter.
• Wenn möglich teste jeden Übergabeparameter ob die Methode auf Grenzwerte (negative Zahlen, zu große Werte usw.) korrekt reagiert. Teste weiterhin, ob die Eingabewerte nur korrekte Werte annehmen können, (z.B. kein 30. Februar bei einer Datumgsübergabe). Teste auf Nullwerte und bei nicht typsicheren Sprachen, wie PHP, ob falsche Typen übergeben werden können, Beispiel: String erwartet, Array übergeben)
• Falls möglich teste sämtliche Pfade (Pfadabdeckung) innerhalb der Methode.

Beispiel:

if($i == 0){ // do something }else{ // do something else } Hier sind zwei Pfade zu überprüfen. Nur wenn beide Pfade vernünftig reagieren, kannst du dir sicher sein, dass alles gut ist.

Für Projektleiter und gute Entwickler:

Es ist eine sehr schnelle und effiziente Art zu entwickeln, wenn man nicht mit dem Programm sondern mit den Testfällen anfängt. Die Zeit, die für die Erstellung der Testfällen benötigt wird, wird durch krampfhafte Fehlersuche am Ende des Projekts locker eingespart. Ein einziges Mal war ich mit Unit Tests bei einer Änderung langsamer, da ich vom Observer auf Eventpattern umstellte und dabei viele Testfälle wirklich manuell überarbeiten musste. Dies war jedoch eine Ausnahme. Wenn eine Änderung am System durchgeführt wird, kann mit Unit Test sehr schnell ein Regressionstest durchgeführt und die Funktionalität überprüft werden. Also nochmal: Es ist ein Aberglaube, dass die Erstellung von Unit Tests irgendwie die Entwicklung bremst. Das Gegenteil ist in deutlich über 95% der Fall. Das Einzige was Zeit kostet, ist es als Projektleiter den Mut zu haben diese Vorgehensweise zu wählen und die Einlernzeit neuer Mitarbeiter in Unit Tests. (Die Einlernzeit ist übrigens nicht sehr hoch.) Für Tester ist das auch eine coole Sache. Sie können die Detailkonzepte direkt in automatische Tests überführen und Regressionstests werden regelrecht spaßig!