DevOps – Testen, aber richtig! Klassisch vs. Unit Tests, TDD

Bei der Qualitätssicherung – und die besteht nun einmal hauptsächlich aus Testen – unterscheide ich zwischen dem SOLL und IST Zustand der klassischen Vorgehensweise und Unit Tests durch den Test-First Ansatz (Test-Driven-Development, TDD).

Die Vorgehensweise der Qualitätssicherung im klassischen Sinn (SOLL):

  1. Entwickler schreibt eine Methode, Klasse oder eine Applikation
  2. Wenn genug Zeit vorhanden, meistens nur optional
    • Manuelle Tests starten
    • Unit Tests erstellen
    • Integration Tests erstellen
  3. Wenn genug Zeit vorhanden, meistens nur optional
    • Es werden alle manuellen Tests von Anfang an neu gestartet
    • Es werden alle Unit Tests neu gestartet
    • Es werden alle Integrationstests neu gestartet
  4. Es werden gemeldete Fehler behoben

Die Vorgehensweise der Qualitätssicherung im klassischen Sinn (IST):

  1. Entwicklungsteam schreibt eine Methode, Klasse oder eine Applikation
  2. Es werden Fehler behoben (und ggf. ungewollt weitere erzeugt)
  3. Fehleranalyse dauert sehr lange, Kosten steigen pro Fehlerfall

Die Vorgehensweise der Qualitätssicherung bei Test Driven Development (Test-First Ansatz, ausgeführt zur Entwicklungszeit)

  1. Schreibe einen Test
  2. Starte alle Tests
  3. Stelle sicher, dass der/die Tests grün werden
    => der produktive Code muss geschrieben werden
  4. Starte alle Tests
    1. Der neue Test schlägt fehl (Red)?
      => Fehler beheben und weiter mit 4.
    2. Der neue Test ist okay (Green)
      => Produktiven Code aufräumen (Blue)
    3. Alle Tests sind okay und kein Bedarf den Code aufzuräumen
      =>  Schreibe einen neuen Test (weiter mit 1.)

Dadurch entsteht ein Zyklus, der mit einem fehlschlagenden Test beginnt (RED) und behoben wird (GREEN). Ggf. kann der Code vereinfacht und aufgeräumt werden (BLUE).
Es entwickelt sich dadurch nach und nach der produktive, aufgeräumte Quellcode – in kleinsten Schritten, überschaubar, lesbar und voll automatisiert.

Mein Fazit:
Der Idee hinter TDD steht für mehr Qualität, Stabilität, Wartbarkeit – und das zu jederzeit automatisiert per Knopfdruck

Weitere Empfehlungen zum Thema Unit Tests und Test Driven Development

Werbeanzeigen

Eine Themenübersicht – Coding Dojo bis Pair Programming

Mit den hier gelisteten Artikeln möchte ich Euch einen Einstieg in die verschiedenen Methoden der Agilen (Software-) Entwicklung geben:

  1. Coding Dojo
  2. Agil, Pairing (XP), aber was steckt dahinter?
  3. Standard Prozesse

    Glossar:

    • XP: Extreme Programming
    • Pairing: Pair Programming, ist ein Teil von XP
    • Dojo, Kata: Übung
    • TDD: Ein Methodik, die den Test-First Ansatz verfolgt
    • DevOps: Development trifft auf Operations

Coding Dojo – Insights

Worauf es bei einem Dojo bzw. Code Kata ankommt, habe ich hier beschrieben.

Der Spaßfaktor soll absolut im Vodergrund stehen. Das ist einer der wichtigsten Lerneffekte der letzten Jahre für mich, frei nach Steve Jobs „You only do great work, if you love what you do“.

Hier geht es nicht darum, wie im Alltag unter Zeitdruck die übergebene Aufgabe schnellstmöglich abzuschließen. Sondern es geht um das Lernen, dabei Spaß zu haben, sich gemeinsam mit einem Thema zu beschäftigen und sein bisheriges Wissen mit anderen zu teilen. Daraus entsteht meistens eine Gruppendynamik, die einen voll in ihren Bann zieht. Ein Dojo soll als eine Übung für was neues sein, z.B. JavaScript.

Auch wenn Kollegen anfangs skeptisch sind, lasst euch nicht einschüchtern. Nehmt Euch die Zeit, klärt sie über die Theorie auf und haltet dann kleine Workshops ab – schnappt Euch eine leichte Übung wie z.B. FizzBuzz. Macht daraus einen kleinen Wettbewerb – klassische Methode vs. Pairing mit TDD.

Das Ergebnis wird nicht nur für Euch selbst verblüffend sein, sondern auch bei den anderen ein „Aha“ auslösen. Mit den ersten Multiplikatoren fängt dann das langsame Umdenken an. Geht auf die Leute zu, holt Euch sachliche Kritik ab. Dadurch verbessert ihr Euer eigenes Know-how rund um Workshops, Coaching und Co.

Fangt noch heute an – es kostet nicht viel Zeit und bringt Euch aber in kleinen Schritten nach vorne.

Viel Spaß beim Üben

Coding Dojo – Let`s do it

Was ein Dojo ist und was bei den ersten Schritten zu beachten ist, habe ich bereits hier beschrieben.

Wenn sich die Gruppe auf die grundlegenden Sachen geeinigt hat, kann es auch schon losgehen. Der erste Schritt ist hier meistens der Schwerste – wie fängt man denn am besten an?
Ein kleiner Tipp: Lest Euch die Aufgabenstellung erneut durch und zerschneidet sie in kleinste Teile mit dem Ziel pro Aufgabe mehrere Tests zu erstellen.

Nehmen wir beispielsweise das Kata FizzBuzz – hier geht es darum eine Zahlenreihe von 1 bis 100 auszugeben.
Bei jeder Zahl, die durch drei teilbar ist, soll Fizz ausgegeben werden. Bei jeder Zahl, die durch fünf teilbar ist, soll Buzz ausgegeben werden. Und wenn die Zahl durch drei und fünf teilbar ist, soll FizzBuzz ausgegeben werden.

Wie sieht dann der erste Test aus? Ganz klar. Nimm die erste Ziffer, die Du prüfen willst, und stelle fest, ob eine der Regeln angewendet werden kann. Danach nimm die zweite Ziffer, usw. Sobald sich die Kombination aus mehreren Regeln ergibt, wird es interessant, da hier auch die Reihenfolge relevant sein kann. Ganz wichtig bei den ersten Schritten – geht streng nach dem Test Driven Prinzip mit Red – Green – Blue vor. Ob ihr lieber Design oder Development nutzt, ist Euch überlassen
Red, d.h. Euer Test muss fehlschlagen.
Green, d.h. Euer Test hat funktioniert.
Blue, d.h. Refactoring – Zeit, um den geschriebenen Code zu verbessern.

Danach geht es mit dem nächsten Test (Red) weiter. Nehmt Euch die Zeit und probiert es aus.