Pyramide oder Kühlturm?

Artikel direkt im Zhlke Blog lesen 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: 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: 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: Das heisst: Der manuelle Test-Aufwand ist gross und die automatisierte Test-Suite läuft lang und ist fragil.

Das eingangs erwähnte Gespräch über den Kühlturm brachte mich dazu, wieder einmal genauer über die Pyramide fr 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): 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:

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.

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:

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? Mehr Artikel von Franziska Meyer