Unit-Tests sind eine tolle Methode von
Extreme Programming (XP). Es geht darum, dass du parallel zu dem Code den du schreibst, auch Tests schreibst, welche die soeben implementierten Funktionen testen.
Optimal ist es so, dass du erst Unittests schreibst und dann die Funktionen, die diese Unittests erfüllen.
Das sieht dann so aus: Du willst eine Funktion schreiben, die das Doppelte von der angegebenen Zahl zurückgibt. Also schreibst du erst einen Unittest, der beispielsweise die Funktion mit dem Wert 2 füttert, und der 4 als Ergebnis erwartet. Nun schreibst du einen weiteren Test, der den String "a" der Funktion übermittelt und testest ob die Funktion einen ValueError ausgibt. Wenn du die Unittest laufen lässt, dann stellst du fest, dass deine Funktion beide Tests nicht besteht, da es sie noch nicht gibt. Also schreibst du eine Funktion die return wert * 2 ausgibt. Dann startest du den test von neuem und stellst fest, dass sie den ersten Test erfüllt, den zweiten jedoch nicht. Nun erweiterst du die Funktion so, dass sie auch den zweiten Test erfüllt und du bist ferig. Oder du schreibst mehr Tests, die die Funktion auf Herz und Nieren prüft.
Test-first Programming (also Unittests schreiben und dann erst den Code) bietet den Vorteil, dass du die API deiner Funktionen so definierst wie du sie brauchst und dann die Funktionen so machst, dass sie die API bereitstellen. Dadurch vermeidest du, dass sich die API ändert, weil sie vorher schlecht war: die API ist von Anfang an so, wie sie sein sollte. Ein weiterer Vorteil ist, dass wenn du eine Funktion änderst und die Unittests ausführst udn diese Funktion nach der änderung noch genausogut Funktioniert wie vorher, dann hast du keine neuen Fehler eingeführt. Das hängt natürlich auch von der Qualität der Unit-Tests ab.
Einen guten Einstieg bietet
Dive Into Python, beginnend mit
Kapitel 13 (Unit testing).
Ich muss sagen, dass ich Unit-Tests viel zu selten schreibe, das gebe ich zu, denn dazu muss man doch auch einiges an Durchhaltevermögen haben. Aber es lohnt sich.
Neben dem in dem Artikel vorgestelltem Modul
unittest und dem ebenfalls in Pyhton mitgeliefertem
doctest gibt es noch
py.test. Alle drei wurden von Grig Gheorghiu
verglichen, jedoch gibt es noch TurboGears'
TestGears, welches vermutlich in TurboGears 0.9 von
nose ersetzt wird.