29. November 2006, 23:14, by Silvan Mühlemann

Teste häufig: Jede Stunde. Automatisch.

Acid Test for Browsers“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.

Selenium Periodical Tester

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.

Failed Test

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.

Filed under: Programming,Web Development

3 Comments

  1. 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.

    Comment by leo — 30. November 2006 @ 14:22

  2. 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… :-)

    Comment by Silvan Mühlemann — 30. November 2006 @ 22:05

  3. 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.

    Comment by leo — 1. December 2006 @ 13:06

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

© 2017 tilllate Schweiz AG - Powered by WordPress