Lead by example – Einführung von Unit Tests

Lesetipps

1. Unit Tests ohne Continuous Integration sind sinnlos
2. Eigentlich machen wir schon Unit Tests
3. Unit Tests – Was sollte man testen?

Heute will ich mal ein paar Worte verlieren über die Einführung von Unit Tests. Dabei möchte ich gar nicht den technischen Hintergrund beleuchten, sondern vielmehr die Kommunikation mit dem Team, wenn man sich entschieden hat diesen Schritt zu gehen.

Aber vielleicht verliere ich erst mal ein paar Worte dazu, wie wir es probiert haben. In unserem Projekt haben wir uns vor circa einem Jahr entschieden, ein wenig mehr auf Qualität zu setzen und Komponenten Tests einzuführen. Wenn ich wir sage, dann meine ich “mich”.  Es war der Versuch das ganze von oben einzuführen. Die Entwickler hatten zwar nichts dagegen, aber wenn sie es nicht machen müssten, dann würden sie es auch nicht von sich selbst aus einführen.

Wir hatten also das Problem, dass kaum neue Tests geschrieben wurden. Leider hat es auf diesen Weg nicht funktioniert. Der Einzige, der anfänglich Tests geschrieben hat war ich. Ich glaube am Anfang war die Aufteilung unter uns drei PHPlern 40/1/0 Units Tests pro Person. Das war leider nicht das Ergebnis, das ich mir erhofft hatte. Wir haben aber trotzdem weiter gemacht und zwar bis zu dem Punkt bis einer meiner Unit Tests einem anderen den Arsch gerettet hat (sorry übrigens ffür den Ausdruck, aber nur falls meine Eltern oder so mitlesen).

Ab dem Tag hat es irgendwie Klick gemacht. Das Finden dieses Fehlers hätte in einem späterem Stadium Stunden dauern könne, da es wirklich nicht offensichtlich war, dass es so eine Auswirkung an einer anderen Stelle geben würde. Seitdem ist das Schreiben von Tests fast zur Routine geworden, jeder hat erkannt wie wichtig und sinnvoll sie sind.

Ok. Lange Rede kurzer Sinn. Was will ich also damit sagen. Ich weiß es nicht, aber ich versuche mal für mich zu definieren, wie ich vorgehen würde, wenn ich noch einmal in einem Team Unit Tests einführen müsste.

1. Benefit definieren
   Erster Schritt wäre wohl ein paar Daten über Komponenten Tests zu sammeln, die aussagekräftig sind und die Leute inspirieren voll einzusteigen.
2. Beispiel- bzw. Vorzeigetests schreiben
   An schönen Beispielen kann man viel einfacher erläutern wie Unit Tests funktionieren
3. Regeln definieren
   “Neuer Code muss mit Unit Tests abgedeckt sein, alter Code beim fixen von Bugs” (sage ich in einem anderen Beitrag mal mehr zu)
4. Lead by Example
   Ganz wichtig ist, dass mindestens eine Person hinter den Tests steht. Diese Person darf sich nicht beirren lassen, falls die anderen keine Tests schreiben. Irgendwann werden sie mit einsteigen.
5. Zeit geben
   Die Entwickler dürfen nicht das Gefühl haben, dass sie in der gleichen Zeit jetzt den Code und die Tests schreiben müssen. Druck hilft hier nämlich gar nichts. Auch wenn man anfänglich mehr Zeit braucht, gewinnt man diese später. Aber genau das sollte ja im Punkt 1) schon geklärt sein.

Wenn ich mir das so anschaue, dann würde ich es wieder ganz ähnlich machen. Irgendwie hat es ja doch geklappt. Natürlich ist es immer besser, wenn das Team sagt, dass sie Tests wollen.

6 Kommentare »

• 
  

  unset

  am 24. Februar 2009 um 08:52 Uhr

  Wenn man entwickler erst in richtung unit tests prügeln muss, sollte man sich deren qualifikationen noch einmal genauer ansehen.

  Ich schreibe grade einen artikel über release-zyklen und wie man tests (nicht nur komponententests) in eben solche integriert. Da gehe ich auf diese problematik auch nochmal ein.

• 
  

  Nils Langner

  am 24. Februar 2009 um 09:00 Uhr

  So würde ich es nicht sehen. Es gibt genügend brilliante Entwickler die ich kenne, die sich weigern Tests zu schreiben. Es kommt auch immer auf die Sprache an. Ich denke Leute mit einem Java Hintergrund ist es in die Wiege gelegt, aber bei C oder C++ Entwicklern ist es nicht an der Tagesordnung.
  Und wenn man 5 Jahre ohne Tests PHP programmiert hat und es hat trotzdem im großen und Ganzen geklappt, dann wird es halt schwer.

• 
  

  unset

  am 24. Februar 2009 um 09:31 Uhr

  Naja. Unit tests gibt es für PHP nicht erst seit PHPUnit. Und auch Sun hat Unit tests nicht erfunden. Und vor allem die Aussage “das haben wir schon immer so gemacht und das hat immer funktioniert” sollte alle Alarmglocken schrillen lassen (“Angry monkeys”).

  Ein erstmal exzellenter Autofahrer, der in 20 Jahren keinen Unfall gebaut hat, sich aber trotzdem und beständig weigert, sich anzuschnallen, ist in meinen Augen erstens schlecht und zweitens nicht willens, sich selbst zu verbessern – auf Programmierung bezogen sind das für mich zwei Indizien für einen schlechten Entwickler. Da könnte man jetzt noch eine ganze Reihe anderer Argumente und Vergleiche heranziehen – abder das würde zu weit führen.

  Übrigens: Ich sagte ja auch nur, dass es Indizien, Hinweise und mögliche Signale sind. Finit kann man das eh nicht mit einer Schablone klären

• 
  

  Nils Langner

  am 24. Februar 2009 um 10:38 Uhr

  Ok, dann einigen wir uns darauf

• 
  

  Ralph Meier

  am 25. Februar 2010 um 06:38 Uhr

  Wie sind Eure Erfahrungen so bezüglich Unit-Testing und dem Verbreitungsgrad? Ich beschäftige mich ja seit ca. 3 Monaten mit diesem Thema und inzwischen ist mir völlig klar, das dies ein absolutes must ist.

  Vorher habe ich in 3 verschiedenen Firmen in 5 Jahren Arbeitswelt noch nie etwas davon gehört und es wurde auch nicht angewendet in meinen Geschäften. Ich hatte dort in Java und PHP Teams entwickelt.

  Ich habe auch viele nicht repräsentative Umfragen unter Ex-Studienkollegen und sonstigen Leuten gemacht. Es hat sich für mich ergeben, dass nur ca. 20-30% überhaupt Unit Testing anwenden. Ist diese Zahle möglich?

  In der Online-Community in der ich mich momentan bewege, scheint Unit Testing völlig normal zu sein. Ist es aber in der “realen” Welt auch so? Mir scheint dem überhaupt nicht so, was meint ihr dazu?

• 
  

  Gamewalker

  am 25. Februar 2010 um 13:44 Uhr

  Ich habe die Erfahrung gemacht, dass bei kleineren Projekten die meisten Leute keine Unit Tests benutzen, aber umso größer das Projekt wird und damit auch unübersichtlicher, das Sie anfangen die Unittests nachzurüsten da Sie schon bei kleinen Änderungen an anderen Stellen ihre Probleme bekommen.

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

Hinterlasse einen Kommentar