Hier erfahren Sie, wie Sie verschiedene Testtypen zu einer sinnvollen Strategie kombinieren, die zu Ihrem Projekt passt.
Willkommen zurück! Im letzten Artikel haben wir die Grundlagen für die verschiedenen Testtypen und deren Inhalte gelegt und die Definitionen der Testtypen geklärt. Erinnern Sie sich an dieses kleine Meme-Bild? Vielleicht haben Sie sich gefragt, wie all die Testtypen, die Sie kennengelernt haben, zusammenarbeiten können.
Als Nächstes erfahren Sie genau das. In diesem Artikel wird beschrieben, wie Sie diese Testtypen zu sinnvollen Strategien kombinieren und eine Strategie auswählen, die zu Ihrem Projekt passt.
Sie können die Strategien mit einer Reihe von Formen vergleichen, um ihre Bedeutung besser zu verstehen. Hier ist eine Liste von Strategien mit den jeweiligen Größen und Entwicklungsumfängen.
Sehen wir uns die Strategien und die Bedeutung ihrer Namen genauer an.
Testziele festlegen: Was möchten Sie mit diesen Tests erreichen?
Bevor Sie eine gute Strategie entwickeln können, müssen Sie Ihr Testziel festlegen. Wann ist Ihre Anwendung Ihrer Meinung nach ausreichend getestet?
Eine hohe Testabdeckung wird von Entwicklern oft als das ultimative Ziel beim Testen angesehen. Aber ist das immer der beste Ansatz? Es gibt noch einen weiteren wichtigen Faktor, den Sie bei der Entscheidung für eine Teststrategie berücksichtigen sollten: die Anforderungen Ihrer Nutzer.
Als Entwickler verwenden Sie auch viele andere Anwendungen und Geräte. In dieser Hinsicht sind Sie der Nutzer, der sich darauf verlässt, dass alle diese Systeme „einfach funktionieren“. Sie verlassen sich also darauf, dass unzählige Entwickler ihr Bestes geben, damit ihre Anwendungen und Geräte funktionieren. Als Entwickler möchten Sie diesem Vertrauen natürlich gerecht werden. Ihr erstes Ziel sollte also immer sein, funktionierende Software bereitzustellen und Ihre Nutzer zu bedienen. Das gilt auch für die Tests, die Sie schreiben, um die Qualität der Anwendung zu gewährleisten. Kent C. Dodds fasst es in seinem Beitrag Static vs Unit vs Integration vs E2E Testing for Frontend Apps sehr gut zusammen:
Je mehr Ihre Tests der tatsächlichen Nutzung Ihrer Software entsprechen, desto zuverlässiger sind sie.
von Kent C. Dodds
Kent beschreibt es als „Vertrauen in Tests gewinnen“. Je näher Sie den Nutzern kommen, indem Sie einen geeigneten Testtyp auswählen, desto mehr können Sie darauf vertrauen, dass Ihre Tests gültige Ergebnisse liefern. Mit anderen Worten: Je höher Sie in der Pyramide aufsteigen, desto sicherer werden Sie. Aber was ist die Pyramide?
Teststrategien festlegen: So wählen Sie eine Teststrategie aus
Bestimmen Sie zuerst, welche Teile der Anforderungen Sie prüfen müssen, um sicherzustellen, dass sie erfüllt sind. Finden Sie heraus, welche Testtypen Sie verwenden sollten und mit welchem Detaillierungsgrad Sie die größte Zuverlässigkeit erreichen, während Sie gleichzeitig eine effiziente Kostenstruktur beibehalten. Viele Entwickler nähern sich diesem Thema mithilfe von Analogien. Hier sind die gängigsten, beginnend mit dem bekannten Klassiker.
Der Klassiker: Die Testpyramide
Sobald Sie sich mit Teststrategien beschäftigen, werden Sie wahrscheinlich als Erstes auf die Testautomatisierungspyramide stoßen. Mike Cohn hat dieses Konzept in seinem Buch „Succeeding with Agile“ vorgestellt. Später erweiterte Martin Fowler das Konzept in seinem Artikel The Practical Test Pyramid. Sie können die Pyramide visuell so darstellen:
Wie in dieser Zeichnung dargestellt, besteht die Testpyramide aus drei Ebenen:
Einheit. Diese Tests befinden sich auf der untersten Ebene der Pyramide, da sie schnell ausgeführt werden können und einfach zu verwalten sind. Sie sind isoliert und zielen auf die kleinsten Testeinheiten ab. Hier ist ein Beispiel für einen typischen Unit-Test für ein sehr kleines Produkt.
Integration. Diese Tests befinden sich in der Mitte der Pyramide, da sie eine akzeptable Ausführungsgeschwindigkeit haben, aber näher am Nutzer sind als die Unit-Tests. Ein Beispiel für einen Integrationstest ist ein API-Test. Sie können auch Komponententests als diesen Typ klassifizieren.
E2E-Tests (auch UI-Tests genannt). Diese Tests simulieren einen echten Nutzer und seine Interaktion. Solche Tests benötigen mehr Zeit für die Ausführung und sind daher teurer. Sie stehen an der Spitze der Pyramide.
Konfidenz im Vergleich zu Ressourcen
Wie bereits kurz erwähnt, ist die Reihenfolge der Schichten kein Zufall. Sie zeigen die Prioritäten und die entsprechenden Kosten. So erhalten Sie ein klares Bild davon, wie viele Tests Sie für jede Ebene schreiben sollten. Sie haben dies bereits in der Definition der Testtypen gesehen.
Da E2E-Tests am nächsten an Ihren Nutzern sind, geben sie Ihnen die größte Sicherheit, dass Ihre Anwendung wie beabsichtigt funktioniert. Sie erfordern jedoch einen vollständigen Anwendungs-Stack und einen simulierten Nutzer und sind daher potenziell auch die teuersten. Die Konfidenz steht also in direktem Wettbewerb mit den Ressourcen, die Sie für die Durchführung der Tests benötigen.
Die Pyramide versucht, dieses Problem zu lösen, indem sie Sie dazu bringt, sich mehr auf Unit-Tests zu konzentrieren und die von E2E-Tests abgedeckten Fälle strikt zu priorisieren. Beispiele hierfür sind die wichtigsten User Journeys oder die Bereiche, die am anfälligsten für Fehler sind. Wie Martin Fowler betont, sind die beiden wichtigsten Punkte in Cohns Pyramide:
- Tests mit unterschiedlicher Granularität schreiben
- Je höher die Ebene, desto weniger Tests sollten Sie haben.
Pyramide hat sich weiterentwickelt. Anpassungen der Testpyramiden
Seit mehreren Jahren drehen sich die Diskussionen um die Pyramide. Die Pyramide scheint die Teststrategien zu stark zu vereinfachen, lässt viele Testtypen aus und passt nicht mehr zu allen realen Projekten. Daher kann sie irreführend sein. Hat die Pyramide ihre Form verloren? Guillermo Rauch hat eine Meinung dazu:
Tests schreiben aber nicht zu viele. Hauptsächlich Integration.
von Guillermo Rauch
Es ist eines der am häufigsten zitierten Zitate zu diesem Thema. Sehen wir uns das einmal genauer an:
- „Tests schreiben“. Nicht nur, weil es Vertrauen schafft, sondern auch, weil es Zeit bei der Wartung spart.
- „Nicht zu viele“. Eine Abdeckung von 100 % ist nicht immer gut, da Ihre Tests dann nicht priorisiert werden und viel Wartung erforderlich ist.
- „Überwiegend Integration“ Auch hier liegt der Schwerpunkt auf Integrationstests: Sie haben den größten geschäftlichen Wert, da sie Ihnen täglich ein hohes Maß an Vertrauen bieten und gleichzeitig eine angemessene Ausführungszeit ermöglichen.
Das bringt Sie dazu, die Testpyramide noch einmal zu überdenken und Ihren Fokus auf Integrationstests zu verlagern. In den letzten Jahren wurden viele Anpassungen vorgeschlagen. Sehen wir uns die gängigsten an.
Testdiamant
Die erste Anpassung entfernt die Überbetonung von Unittests, wie sie in der Testpyramide zu sehen ist. Angenommen, Sie haben eine 100%ige Abdeckung bei Unittests erreicht. Wenn Sie jedoch das nächste Mal refaktorieren, müssen Sie viele dieser Unit-Tests aktualisieren und sind möglicherweise versucht, sie zu überspringen. Sie erodieren also.
In Kombination mit dem stärkeren Fokus auf Integrationstests kann sich daraus die folgende Form ergeben:
Eine Pyramide wird zu einem Diamanten. Sie sehen die vorherigen drei Ebenen, aber mit einer anderen Größe, und die Einheitenebene wurde entfernt:
- Einheit. Schreiben Sie Unittests so, wie Sie sie zuvor definiert haben. Da sie jedoch dazu neigen, sich zu verschlechtern, sollten Sie sie priorisieren und nur die wichtigsten Fälle abdecken.
- Integration. Integrationstests, bei denen die Kombination einzelner Einheiten getestet wird.
- E2E. Diese Ebene verarbeitet die UI-Tests ähnlich wie die Testpyramide. Schreiben Sie E2E-Tests nur für die wichtigsten Testfälle.
Honeycomb testen
Es gibt eine weitere Anpassung, die von Spotify eingeführt wurde. Sie ähnelt der Testpyramide, ist aber weiter auf mikrodienstbasierte Softwaresysteme spezialisiert. Die Testwabe ist eine weitere visuelle Analogie für die Granularität, den Umfang und die Anzahl der Tests, die für ein auf Mikrodiensten basierendes Softwaresystem geschrieben werden müssen. Aufgrund ihrer geringen Größe liegt die größte Komplexität eines Mikrodienstes nicht im Dienst selbst, sondern in der Interaktion mit anderen Diensten. Eine Teststrategie für einen Mikrodienst sollte sich daher hauptsächlich auf Integrationstests konzentrieren.
Diese Form erinnert an eine Bienenwabe, daher der Name. Es hat die folgenden Layer:
- Integrierte Tests: Im Artikel von Spotify wird ein Zitat von J. B. Rainsberger, um diese Ebene zu definieren: „Ein Test, der je nach Korrektheit eines anderen Systems bestanden wird oder fehlschlägt.“ Solche Tests haben externe Abhängigkeiten, die Sie berücksichtigen müssen. Umgekehrt kann Ihr System eine Abhängigkeit sein, die andere Systeme beeinträchtigt. Ähnlich wie E2E-Tests in anderen Analogien sollten Sie diese Tests nur für die wichtigsten Fälle verwenden.
- Integrationstests: Ähnlich wie bei anderen Anpassungen sollten Sie sich auf diese Ebene konzentrieren. Sie enthält Tests, mit denen die Korrektheit Ihres Dienstes isolierter, aber dennoch in Kombination mit anderen Diensten überprüft wird. Das bedeutet, dass die Tests auch andere Systeme umfassen und sich auf die Interaktionspunkte konzentrieren, z. B. über API-Tests.
- Tests zu Implementierungsdetails. Diese Tests ähneln Unit-Tests, die sich auf Teile des Codes konzentrieren, die von Natur aus isoliert sind und daher eine eigene interne Komplexität haben.
Weitere Informationen zu dieser Teststrategie finden Sie im Beitrag von Martin Fowler, in dem die Testpyramide mit der Wabe verglichen wird, und im Originalartikel von Spotify.
Testtrophäe
Sie können bereits einen wiederkehrenden Fokus auf Integrationstests erkennen. Ein weiterer Typ, den Sie im vorherigen Artikel kennengelernt haben, ist jedoch kein Test im theoretischen Sinne, aber dennoch ein wichtiger Aspekt, den Sie in einer Teststrategie berücksichtigen sollten. Die statische Analyse fehlt in der Testpyramide und in den meisten Anpassungen, die Sie bisher gesehen haben. Es gibt die Anpassung der Testtrophäe, die die statische Analyse berücksichtigt, während der Fokus auf Integrationstests bleibt. Die Testtrophäe stammt aus dem früheren Zitat von Guillermo Rauch und wurde von Kent C. Dodds:
Die Testtrophäe ist eine Analogie, die die Granularität von Tests auf etwas andere Weise darstellt. Sie besteht aus vier Schichten:
- Statische Analyse: Sie spielt in dieser Analogie eine wichtige Rolle und ermöglicht es Ihnen, Tippfehler, Stilfehler und andere Fehler zu finden, indem Sie einfach die bereits beschriebenen Schritte zur Fehlerbehebung ausführen.
- Einheitentests: Sie sorgen dafür, dass die kleinste Einheit angemessen getestet wird, aber die Testtrophäe legt nicht so viel Wert auf sie wie die Testpyramide.
- Integration. Dies ist der Hauptfokus, da hier wie bei anderen Anpassungen die Kosten und die höhere Konfidenz am besten ausgeglichen werden.
- UI-Tests: E2E- und visuelle Tests befinden sich an der Spitze der Testtrophäe, ähnlich wie in der Testpyramide.
Weitere Informationen zur Testtrophäe finden Sie im Blogpost von Kent C. Dodds zu diesem Thema.
Einige eher UI-orientierte Ansätze
Das ist alles schön und gut, aber egal, wie Sie Ihre Strategie nennen, ob „Pyramide“, „Wabe“ oder „Diamant“, es fehlt immer noch etwas. Die Testautomatisierung ist zwar wertvoll, aber manuelle Tests sind nach wie vor unerlässlich. Automatisierte Tests sollten Routineaufgaben reduzieren, damit sich die Qualitätssicherungsingenieure auf wichtige Bereiche konzentrieren können. Automatisierung sollte manuelle Tests nicht ersetzen, sondern ergänzen. Gibt es eine Möglichkeit, manuelle Tests mit Automatisierung zu kombinieren, um optimale Ergebnisse zu erzielen?
Test-Eiswaffel und Test-Krabbe
Es gibt tatsächlich zwei Anpassungen der Testpyramide, die sich mehr auf diese UI-orientierten Testmethoden konzentrieren. Beide haben den Vorteil einer hohen Konfidenz, sind aber aufgrund der langsameren Testausführung natürlich teurer.
Der erste, der Test-Eiskegel, sieht aus wie die umgekehrte Pyramide. Ohne den manuellen Testschritt wird sie auch als Testpizza bezeichnet.
Beim Eiskegel liegt der Schwerpunkt auf manuellen oder UI-Tests und der geringste Fokus auf Unit-Tests. Sie entsteht oft in Projekten, bei denen Entwickler mit nur wenigen Gedanken zur Teststrategie mit der Arbeit begonnen haben. Der Ice-Code gilt zu Recht als Anti-Pattern. Er ist in Bezug auf Ressourcen und manuelle Arbeit kostspielig.
Die Testkrabbe ähnelt der Testeiswaffel, legt aber mehr Wert auf E2E- und visuelle Tests:
Diese Teststrategie umfasst einen weiteren Aspekt: Sie prüft, ob Ihre Anwendung funktioniert und gut aussieht. Die Testkrabbe hebt die Bedeutung von visuellen Tests hervor, die im vorherigen Artikel definiert wurden. Integrationstests, die in Komponenten- und API-Tests unterteilt sind, rücken weiter in den Hintergrund und Unittests spielen hier eine noch untergeordnetere Rolle. Weitere Informationen zu dieser Teststrategie finden Sie in diesem Artikel zur Testkrabbe.
Diese beiden Teststrategien sind zwar teurer, haben aber ihre Berechtigung: zum Beispiel bei kleineren Projekten, bei denen weniger Tests erforderlich sind oder weniger Komplexität abgedeckt werden muss. In diesem Fall wäre eine umfassende Teststrategie mit Schwerpunkt auf Integrationstests möglicherweise übertrieben.
Diese beiden Teststrategien sind zwar teurer, haben aber ihre Berechtigung, z. B. bei kleineren Projekten, die weniger Tests erfordern und nicht sehr komplex sind. In diesem Fall ist eine umfassende Teststrategie, die sich auf Integrationstests konzentriert, möglicherweise unnötig komplex.
Praktische Tipps: Strategie entwickeln
Sie haben nun die gängigsten Teststrategien kennengelernt. Sie haben mit dem Klassiker – der Testpyramide – begonnen und ihre vielen Anpassungen kennengelernt. Jetzt müssen Sie sie für Ihr Produkt bewerten und entscheiden, welche am besten für Ihr Projekt geeignet ist. Die Antwort auf diese Frage lautet: Das kommt darauf an. Das macht sie aber nicht weniger genau.
Welche der beschriebenen (und auch der nicht beschriebenen) Teststrategien am besten geeignet ist, hängt von Ihrer Anwendung ab. Sie sollte zu Ihrer Architektur, Ihren Anforderungen und nicht zuletzt zu Ihren Nutzern und deren Anforderungen passen. All dies kann von Anwendung zu Anwendung variieren. Das ist völlig normal. Denken Sie daran, dass Ihr wichtigstes Ziel darin besteht, Ihre Nutzer zu bedienen, und nicht darin, eine Lehrbuchdefinition zu erfüllen.
In der Regel ist es schwierig, Tests in der Praxis zu trennen und einzeln zu definieren. Sogar Martin Fowler selbst betont den positiven Aspekt unterschiedlicher Definitionen, wie im Fall von Unit-Tests. Wie Justin Searls in seinem Tweet richtig feststellt:
[…] aussagekräftige Tests schreiben, die klare Grenzen setzen, schnell und zuverlässig ausgeführt werden und nur aus nützlichen Gründen fehlschlagen.
von Justin Searls
Konzentrieren Sie sich auf die Tests, die tatsächliche Fehler melden, die bei Nutzern auftreten können, und lassen Sie sich nicht von Ihrem Ziel ablenken. Tests sollten so konzipiert sein, dass sie dem Nutzer nützen, und nicht nur eine 100%ige Abdeckung bieten oder dazu dienen, darüber zu diskutieren, welcher Prozentsatz welcher Testart geschrieben werden soll.
Konzentrieren Sie sich auf Tests, die reale Fehler melden, die bei Ihren Nutzern auftreten könnten, und lassen Sie sich nicht von Ihrem Ziel ablenken. Tests sollten so konzipiert sein, dass sie dem Nutzer zugutekommen, und nicht nur eine 100%ige Abdeckung bieten oder Debatten darüber auslösen, wie viel Prozent eines bestimmten Testtyps Sie schreiben sollten.