Unit Tests ohne Continuous Integration sind sinnlos

Lesetipps

1. Lead by example – Einführung von Unit Tests
2. Eigentlich machen wir schon Unit Tests
3. Unit Tests – Was sollte man testen?

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.

10 Kommentare »

• 
  

  Dennis Becker

  am 18. September 2009 um 09:50 Uhr

  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

• 
  

  maren

  am 18. September 2009 um 10:43 Uhr

  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.

• 
  

  Tobias Petry

  am 18. September 2009 um 11:09 Uhr

  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.

• 
  

  Nils Langner

  am 18. September 2009 um 11:13 Uhr

  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.

• 
  

  Stephan Hochdoerfer

  am 18. September 2009 um 11:21 Uhr

  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/

• 
  

  Nils Langner

  am 18. September 2009 um 11:26 Uhr

  @Stephan: Irgendwie wurde ich mit trac nie so wirklich warm. Hast du damit so gute Erfahrungen gemacht?

• 
  

  Stephan Hochdoerfer

  am 18. September 2009 um 11:38 Uhr

  @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?

• 
  

  Nils Langner

  am 18. September 2009 um 11:55 Uhr

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

• 
  

  Christopher K.

  am 18. September 2009 um 15:32 Uhr

  soso, der Nils heißt jetzt “admin”
  Ok, sorry, is off topic, is mir nur so aufgefallen ^^

• 
  

  Arne

  am 21. September 2009 um 07:59 Uhr

  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 !

RSS Feed für Kommentare zu diesem Artikel. TrackBack URL

Hinterlasse einen Kommentar