Kategorien
Unit Tests ohne Continuous Integration sind sinnlos
Nicht das gestern schon wieder eine neue Ausgabe des PHP Magazins besprochen wurde, nein heute ist auch schon wieder Freitag. Also Ende der Woche. Nichts mehr zu arbeiten die nächsten zwei Tage. Super. Ach ja, ich habe heute übrigens frei. Nur so zum neidisch machen. Ich werde also bis 11 Uhr im Bett bleiben. Denkst also dran, dass wenn ihr das hier lest ich noch im Land der Träume liegen werde. Zumindest ist das der Plan. Die Realität wird mich aber bestimmt um 6 Uhr wecken, so wie jeden Tag. Aber um ehrlich zu sein: Ich glaube das interessiert euch gar nicht.
Wechseln wir also wieder zu einem phphatesme würdigen Thema. Ich habe übrigens nur so eine lange Einleitung, weil ich nicht weiß, was ich heute schreiben soll. Tadaaa … der Geistesblitz kam. Und ihr kennt natürlich schon das Thema, denn die Überschrift verrät sie euch ja.
Es geht um Unit Tests. Ich denke mal dran, dass immer mehr von euch Tests schreiben. Zumindest war das das Gefühl, dass ich von der Unconference und auch von der IPC im letzten Jahr mitgenommen habe. Ich habe aber auch oft Leute gesehen, die zwar testen, aber keinen Continuous Integration Server, wie phpUnderControl oder Bamboo nutzen. Dummerweise konnte man immer ein Resultat bei dieser Verwendung feststellen. Man hat anfänglich getestet, bis man mit einer Komponente fertig war. So weit, so gut. Komponente gewechselt und wieder bis zum Schluss durchgezogen. Wenn man jetzt aber schnell mal die erste Komponente anpasst ist das ja auch kein Problem. Wenn es wirklich schnell gehen soll, dann passt man die Unit Tests auch nicht wirklich mehr an. Wenn die Zeit vergeht, funktionieren immer mehr Unit Tests nicht. Oder besser: es funktionieren immer weniger.
Wenn mal die kritische Masser erreicht ist, dann hat man auch keine Lust mehr zu reparieren und läßt die Tests einfach Links liegen, auch wenn sie eines der mächtigsten qualitätssichernden Maßnahmen sind. Schade eigentlich. Wäre ein Continuous Integration Server aktiv gewesen, so hätte der einen schon beim ersten Fehler so lange genervt, bis man nachgegeben hätte. Das kleine vollautomatisierte „sind wir bald da“ Tool also. Je früher man Fehler behebt, desto einfacher ist es. Wie immer in der Softwareentwicklung.
Ob das immer so ablaufen muss, weiss ich nicht, das sind nur meine Erfahrungswerte. Bei Projekten, die länger laufen, also die Entwicklungszeit einer Komponente, sei also immer der Einsatz einer CI Lösung empfohlen. Die Installation ist kein Hexenwerk und der Vorteil ungemein. Wie man ein phpUnderControl aufsetzt, werden wir auch bald hier besprechen, dann hat niemand mehr eine Entschuldigung.
Jetzt versteh ich auch, warum du letztens meintest, ihr wollt „Bamboo“ einsetzen. Wenn man die Software von Atlassian eh schon im Einsatz hat, will man denke ich mal eher auf das selbe Pferd als auf viele einzelne setzen (meine Theorie).
Und ich muss dir da auch vollkommen zustimmen. Ich hab auch so eine Komponente, die je nach Eingabedaten ein anderes verhalten an den Tag legen muss. Für jede mögliche Kombination gibt es einen eigenen TestCase – und nur wenn alle fehlerfrei sind, kann ich sicher sein, dass meine letzte Änderung nicht 5 von 15 Fällen kaputt gemacht hat 😀
Das Thema CI kann ich nun garnicht mehr abwarten 🙂
Ich denke es gibt auch ohne CI Infrastruktur die Möglichkeit regelmäßig Metriken zu erzeugen und Tests automatisiert ablaufen zu lassen.
Ich habe mir mit einem Cronjob plugin ausgeholfen, welches antbuilds automatisiert abfeuert. Unterm strich machen die großen CI-Umgebungen ja auch nichts anderes.
Das Problem wird wohl sein, dass Bamboo ne ganze Ecke Geld kostet und phpUnderControl alles andere als leicht zu installieren ist, die ganze XML-Configurationsgeschichte von CruiseControl ist einfach nur nervig.
genau wir verwenden Bamboo um eine homogene Infrastruktur hinzubekommen. Confluence, Bamboo, Jira und noch den Source COde Aufsatz. Klar kostet es viel, aber ich denke wir haben das schnell wieder raus, wenn es sich alles nahtlos integrieren lässt.
Davor hatten wir auch phpUnderControl und ich fand es eine tolle Sache.
Ich finde Trac[1] und das bitten Plugin[2] eine feine Sache. Recht simpel gehalten, lässt sich aber einfach installieren und kost nix 🙂
[1] http://trac.edgewall.org/
[2] http://bitten.edgewall.org/
@Stephan: Irgendwie wurde ich mit trac nie so wirklich warm. Hast du damit so gute Erfahrungen gemacht?
@Nils: Wir nutzen Trac schon recht lange, seit Ende 2005 wenn ich mich recht erinnere. Im Grund bietet es alles was wir brauchen, bis dato hatten wir nie wirklich Probleme und durch die vielen Plugins kann man schon einiges customizen. Was für Probleme hattest/hast du mit Trac?
@Stephan: Kam mit dem Wiki nicht so wirklich zurecht. Kann aber auch dran liegen, dass wir kaum/keine PlugIns installieren durften. Das erschwert natürlich alles.
soso, der Nils heißt jetzt „admin“ 😉
Ok, sorry, is off topic, is mir nur so aufgefallen ^^
Moin,
ich handhabe es so : Vor jedem Release, sei es Q System oder Produktion lasse ich ein Build Script (phing) laufen, dieses führt über einen Task PHPUnit tests durch, schlagen diese fehl, kein build 🙂
Nebenbei natürlich auch noch eine Cruise Control !