en
de

Pyramide oder Kühlturm?

9 Juni 2015
| |
Lesezeit: 3 Minutes

Kühlturm, Vase, Ice-Cream Cone, Luftballon oder Pyramide: welche Form haben ihre Tests? Sind sie robust oder haben Sie manchmal das Gefühl, dass die Tests möglicherweise sogar vom Wetter abhängig sind? Sind die wichtigsten Tests schnell genug, dass Sie sie nach jeder Änderung ausführen, oder warten Sie stundenlang auf Feedback? Sind Ihre Tests einfach anzupassen oder bremsen sie die Entwicklung aus?

Kürzlich erzählte ein Kollege vom Kühlturm – einige Tests auf Unit-Ebene, weniger auf Service- oder Integrations-Ebene, wieder mehr auf UI-Ebene und darüber eine riesige Wolke von manuellen Tests:

Kühlturm

Mit einem Kühlturm ist Testen zeitintensiv. Da sind einerseits die vielen manuellen Tests, andererseits brauchen aber auch die zahlreichen UI-Tests für jede Durchführung viel Zeit. Dazu kommt, dass die UI-Tests empfindlich sind gegenüber (UI-)Änderungen und (je nach eingesetzten Tools) äusseren Einflüssen. Das heisst: Die UI-Tests sind nicht besonders robust.

Als Variante zum Kühlturm kenne ich die Vase:

Vase

Sie entsteht aus einem Kühlturm, wenn manuelle Tests in Form von UI-Tests automatisiert werden. Einen Teil der manuellen Tests zu automatisieren macht beim Kühlturm sicher Sinn (darum die kleine Blume statt der grossen Wolke). Aber wenn die manuellen Tests mehr oder weniger direkt in UI-Tests überführt werden, dann verschärft dies das Problem mit den fragilen und langsamen UI-Tests.

Eine weitere Verschärfung mit einer noch trägeren und fragileren Test-Suite ist der Ice-Cream Cone, der im Vergleich mit dem Kühlturm kaum Unit-Tests hat:

Ice-Cream Cone

Das heisst: Der manuelle Test-Aufwand ist gross und die automatisierte Test-Suite läuft lang und ist fragil.

Die Pyramide

Das eingangs erwähnte Gespräch über den Kühlturm brachte mich dazu, wieder einmal genauer über die Pyramide für automatisierte Tests von Mike Cohn nachzudenken. Sie besagt, dass es die meisten Tests auf Unit-Ebene und die wenigsten auf UI-Ebene geben soll (das Wölkchen für die manuellen Tests stammt offenbar von Lisa Crispin):

Pyramide

Unit-Tests laufen sehr schnell und können dadurch häufiger ausgeführt werden. Entsprechend schnell decken sie Fehler auf. (Automatisierte) UI-Tests brauchen deutlich mehr Zeit und werden daher seltener ausgeführt. Daher dauert es länger, bis sie Fehler aufdecken. UI-Tests sind ausserdem oft weniger robust als (gut geschriebene) Unit-Tests. Trotzdem sind sie wertvoll, weil sie Abläufe testen, die von den Unit-Tests nicht erfasst werden können.

Die Pyramide basiert auf einer einzigen Regel: Jeder Test ist auf der feinsten Granularitätsstufe, die für diesen spezifischen Fall möglich ist. Dadurch ist der Feedback-Loop so kurz wie möglich.

In mehr Worten:

  • Was ich mit Unit-Tests testen kann, teste ich mit Unit-Tests.
  • Wenn ich etwas nicht mit Unit-Tests testen kann, dann kommen (wenn möglich) Service-Tests zum Zug.
  • Was ich nicht mit Service-Tests testen kann, teste ich mit UI-Tests.
  • Dinge, die ich nicht oder nur mit unverhältnismässig grossem Aufwand automatisieren kann, teste ich manuell.

Ich bin ausschliesslich darauf eingegangen, wie robust die Tests sind und wie schnell sie ausgeführt werden können. Das ist nicht die ganze Wahrheit, denn als dritter Aspekt kommen die Kosten dazu: Wie teuer sind das Erstellen und Warten eines Tests? Während die Kosten bei Unit- und Service-Tests vor allem von der Qualität der Tests (und von der Qualität des Designs) abhängen, spielen bei den UI-Tests auch die gewählten Tools und Test-Strategien eine grosse Rolle.

Fazit

Natürlich gibt es neben den erwähnten Formen noch weitere wie den Luftballon (ausschliesslich manuelle Tests), und möglicherweise machen gewisse Formen in einem speziellen Umfeld sogar Sinn. Doch im Grossen und Ganzen ist das Prinzip klar: Wenn die Tests anders verteilt sind als in einer Pyramide, dann hole ich nicht das Maximum aus ihnen heraus:

  • Ich bekomme ich das Feedback langsamer als nötig.
  • Die Tests sind weniger robust als sie sein könnten.

Das heisst umgekehrt zum Beispiel: Wenn mir der Feedback-Loop zu lang wird, dann könnte es durchaus sein, dass ich eine Vase statt einer Pyramide gebaut habe.

Welche Form haben Ihre Tests?

Kommentare (1)

Avatar

Marko Zivkovic

21 Juni 2016 um 19:17

Danke für den äusserst anschaulichen Beitrag.
Ich habe ihn gerne auf LinkedIn geteilt.

Zusammengefasst: Tests am besten so weit unten wie möglich machen, bzw. so lokal wie möglich. Daher die Pyramidenform. Durch die Lokalität laufen Tests automatisch schneller.

×

Updates

Schreiben Sie sich jetzt ein für unsere zwei-wöchentlichen Updates per E-Mail.

This field is required
This field is required
This field is required

Mich interessiert

Select at least one category
You were signed up successfully.

Erhalten Sie regelmäßige Updates zu neuen Blogartikeln

Jetzt anmelden

Oder möchten Sie eine Projektanfrage mit uns besprechen? Kontakt aufnehmen »