“Teste häufig”, predigt “Der Pragmatische Programmierer”, mein aktuelles Nachttischbuch. Häufiges Testen = automatisches Testen. Denn wer will schon die gleichen Testcases immer und immer wieder durchführen?
Funktionstests machen wir mit Selenium, wie früher schon berichtet. Im Normalfall öffnet man den TestRunner und startet den gewünschten Test per Mausklick.
Für das automatisch ausgelöste Testen kann dem TestRunner der Parameter auto=true übergeben werden: Die Testsuite wird geladen, die Tests werden sofort, ohne Zutun des Benutzers abgespult.
Ueber ein Javascript in einem eigens dafür reservierten PC rufe ich die Testsuite jede Stunde auf.
Was passert nun mit dem Test-Ergebnis? Mit dem Parameter resultsUrl teile ich dem TestRunner mit, er soll die Testergebnisse an die URL /tilllate_postresults/postresults.php POSTen. Beeindruckend, welche Informationen da übermittelt werden: Dauer der Tests, sogar jeder einzelne Testschritt samt Ergebnis. Diese Daten nehme ich per loadHTML() auseinander und füttere sie unserer Testergebnis-Datenbank.
An einem Bereich, wo unsere Entwickler häufig vorbeikommen, werden die Testergebnisse angeschlagen. Wechselt das Lämpchen von grün auf rot, weiss man, dass innerhalb der letzten Stunde ein Bug eingebaut wurde. (Im Beispiel oben habe ich natürlich zu Demozwecken alle Tests failen lassen 🙂
Innerhalb der letzten Stunde. Also innerhalb 100 Zeilen Code. Nicht innerhalb der letzten Woche (=10000 Zeilen Code). Dank dem häufigen Testen hat man die Bugquelle so automatisch eingegrenzt.
Wir machen das gleich jedes mal beim einchecken. Wenn wir einbuchen wird automatisch der Build ausgelöst, das ganze anschliessend automatisch getestet und ein downloadbares und ausführbares Binary erstellt. Fehler werden auf der Webseite angeschlagen und per Mail verschickt, das: http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/Monitor/Devices/BubbleBubbleBuildsInTrouble.rdoc fehlt uns leider noch.
Das ist sehr schlau: Wenn man ein Build-Vorgang hat. Aber bei unserer Website gibt es diesen Vorgang nicht. Ausserdem dauern alle Tests zusammen über eine halbe Stunde. Da müssten wir bei jeder Anpassung eines Skripts ziemlich viel Geduld beweisen… 🙂
Ja, bei Scriptsprachen kann man sich das ganze builden natürlich sparen. Man muss natürlich auch bei uns nicht warten bis das alles durch ist beim einbuchen, der ganze Prozess wird im Hintergrund gestartet und wenn mans vermasselt hat bekommt man automatisch ein böses Mail.
Eine halbe Stunde, da hat sich ja schon einiges angesammelt. Irgendwo im PragProg-Buch (ich bin leider immer noch nicht durch) sollte auch stehen das Tests (und builden) schnell laufen sollten, damit man möglichst schnell Feedback hat. Nebst dem Optimieren von Test kann man zum Beispiel auch zeitaufwendige Tests (meist GUI, DB, Lasttest etc.) weniger regelmässig ausführen.