Die Testpyramide
Seit einigen Monaten stosse ich immer wieder auf das Konzept der Testpyramide. Ich finde dieses Bild sehr passen, da es die wesentlichen Aspekte auf den Punkt bringt. Um ein System wirklich zu testen gilt es mehrere Ebenen anzuschauen. Die Testpyramide zeigt diese auf und vermittelt auf eine leicht verständliche Weise wie sich die Anzahl der Testfälle staffeln soll:
Unit-Tests als Grundlage
Unit-Tests bilden die Basis der Testpyramide. Die kleinstmöglichen Tests sollten sicherstellen dass das System im Kern funktioniert. Eine wichtige Eigenschaft von Unit-Tests: Sie sind Schnell. In wenigen Sekunden sollte man wissen ob es überhaupt Sinn macht die länger laufenden Tests zu starten. Diese Sekunden sind wohlgemerkt nicht für einen einzigen Tests gedacht, sondern für alle Unit-Tests zusammen – womit ein Unit-Test der länger als 1/100 Sekunde dauert schon als langsam gelten muss.
Damit Tests so schnell sind dürfen sie nur wenig testen. Weder eine Verbindung zur Datenbank noch ein Zugriff aufs Dateisystem oder Aufruf eines Webservices ist erlaubt. All diese Abhängigkeiten müssen entfernt werden. Ob dies mittels Konfiguration oder mit Mocks gemacht wird spielt dabei keine Rolle.
Die Geschwindigkeit alleine kann aber nicht das einzige Kriterium für einen Unit-Test sein. Sonst besteht die Testsuite am Ende nur aus leeren Methoden. Das was man testet soll auch noch Sinn machen. Und einem in die richtige Richtung weisen wenn einmal ein Test fehlschlägt. So ist man schnell einmal bei mehreren Kriterien die von Ben Rady und Rod Coffin in "Continuous Testing" mit dieser Abkürzung zusammengefasst werden:
FIRE: Fast, Informative, Reliable and Exhaustive
Integrationstests
Zu wissen dass der eigene Code für sich alleine funktioniert ist ein Anfang. Damit weiss man aber noch nicht ob der Code auch mit anderen Teilen funktioniert. Hier kommen die Integrationstests ins Spiel.
Auf dieser Ebene werden all die Abhängigkeiten angeschaut die man bei den Unit-Tests entfernt hat. Was zuerst nach vermeidbarem Zusatzaufwand aussieht hat sehr wohl seine Berechtigung. Es genügt wenn man das Erzeugen, Speichern, Aktualisieren und Löschen eines Objekts in der Datenbank ein Mal pro Klasse testet. Dies hat die gleiche Aussagekraft (ist aber deutlich schneller) wie wenn man in allen Unit-Tests immer mit den Objekten aus der Datenbank arbeiten würde.
Da weniger Tests mit den Umsystemen nötig sind wirkt sich deren Ausführungsdauer nicht so stark auf die Länge des gesamten Testlaufs aus.
Akzeptanztests
Die Akzeptanztests bilden die Spitze der Testpyramide. Hier gilt es die Anwendung aus Sicht des Benutzers zu testen. Vom GUI durch die Geschäftslogik hin zur Datenbank und den externen Webservices soll hier alles geprüft werden.
Da man bereits weis das sowohl der Kern der Anwendung funktioniert und der auch mit den Umsystemen korrekt zusammenarbeitet benötigt man nur noch wenige Akzeptanztests. Diese dürfen noch einmal langsamer sein als die Integrationstests und sollen als letzte Stufe die Korrektheit der gesamten Anwendung belegen.
Und da es so wenige Tests sind kann man diese auch mit dem Kunden/Endbenutzer besprechen. Müssen wirklich nur die wichtigsten Tests angeschaut werden hat man gute Chancen dass dies auch wirklich gemacht wird.
Reihenfolge & Einschränkungen
Die Testpyramide gibt keine Reihenfolge für die Erstellung der Testfälle vor. Wenn es bei der Ausführung auch am meisten Sinn macht mit den Unit Tests zu beginnen so ist man beim Erstellen frei.
Hat man Glück und der Kunde will an Akzeptanztests mitarbeiten kann man einen Top-Down Ansatz wählen. Man beginnt mit einem fehlgeschlagenen Akzeptanztest und schreibt so lange Integrations- und Unit-Tests bis dieser erfüllt wird. Alternativ kann man aber auch mit den Unit-Tests beginnen und sich nach oben arbeiten.
Die Testpyramide ist aber nicht perfekt. Es gibt etliche Testarten die darin keinen Platz finden. Wo platziert man beispielsweise die Explorationstests? Oder die Performancetests? Trotz dieser Einschränkungen finde ich das Bild der Testpyramide sehr gelungen.