Als Entwickler würde man am liebsten nur isolierte Unittests schreiben. Doch leider liefert eine derartige Testsuite selbst bei hoher Testabdeckung nur mäßig realistische Aussagen zur Funktionsfähigkeit des Gesamtsystems im Zusammenspiel der Einzelteile. Man benötigt also zusätzich integrativere Testarten wie Komponenten- oder Systemtests. Doch diese bringen wiederum andere Probleme mit sich. - Tests werden fragiler und damit schlechter wartbar, - die Fehlersuche bei fehlgeschlagenen Tests dauert lange, da die Anzahl der möglichen Ursachen explodiert und - die Tests laufen lang und liefern (zu) spät Feedback
Bei automatisierten End-To-End-Tests verschärft sich die Situation noch, da angebundene Dritt-(Test-)systeme meist nicht einfach vom eigenen Team beeinflusst werden können, man aber trotzdem von deren Release- und Deployment-Zyklen, Verfügbarkeit und Testdaten abhängt. So schlägt der CI-Job oft fehl, obwohl die eigentliche Software unter Test korrekt funktioniert.
Jede Testart hat Ihre eigenen Stärken und Schwächen und so stellen sich die Fragen: - Wie teste ich die Integration mit Drittsystemen? - Welche Fragestellung teste ich mit welcher Testart? - Wie ergänzen sich die verschiedenen Arten gegenseitig?
Bei der Klärung der Fragen helfen - Ideen aus dem Buch “Growing Object Oriented Software” und Alistair Cockburns “ports-and-adapters”-Architektur, - darüber hinaus ein paar interessante darauf basierende Patterns für Integrationstests von Martin Fowler und Nat Price, - “integration tests are a scam” von J.B. Rainsberger und schlussendlich - die Testpyramide veranschaulicht an einem konkreten Code-Beispiel.
Der Vortrag entwickelt ein ganzheitliches Bild davon, wie sich die verschiedenen Arten automatisierter Tests gegenseitig ergänzen, in Entwicklungsprozess, Continuous Deployment Pipeline und Architektur einfügen und was lieber ein manueller Tester übernehmen sollte. Diese “Landkarte der Testarten” hilft dabei, eine effektive Testautomatisierungsstrategie für das eigene Projekt zu entwickeln, bei der Aufwand und Nutzen über den ganzen Lebenszyklus der Anwendung in einem vernünftigem Verhältnis stehen.
David Völkel arbeitet als IT-Consultant für die codecentric AG. Ihn begeistern Softwaredesign im Kontext testgetriebener Entwicklung. Als bekennender “software craftsman” ist er in der Softwerkskammer aktiv.