Hier erfährst du, wie du verschiedene Testtypen zu einer vernünftigen Strategie kombinieren kannst, die zu deinem Projekt passt.
Willkommen zurück! Im letzten Artikel wurden viele Grundlagen für die Herangehensweise an die verschiedenen Testtypen und deren Inhalt beschrieben. Außerdem wurden die Definitionen der Testtypen klarer formuliert. Erinnern Sie sich an dieses kleine Meme? Vielleicht haben Sie sich gefragt, wie all diese Testtypen, die Sie kennengelernt haben, zusammenwirken könnten.
Als Nächstes erfahren Sie genau das. In diesem Artikel erfahren Sie, wie Sie diese Testtypen zu sinnvollen Strategien kombinieren und eine Strategie auswählen können, 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 entsprechenden Größen und Entwicklungsbereichen.
Sehen wir uns die Strategien und die Bedeutung ihrer Namen genauer an.
Testziele festlegen: Was möchten Sie mit diesen Tests erreichen?
Legen Sie ein Testziel fest, bevor Sie mit der Entwicklung einer guten Strategie beginnen. Wann ist Ihrer Meinung nach Ihre Anwendung ausreichend getestet?
Eine hohe Testabdeckung wird oft als das ultimative Ziel von Entwicklern angesehen, wenn es um Tests geht. Aber ist es immer die beste Herangehensweise? Bei der Entscheidung für eine Teststrategie könnte es einen weiteren entscheidenden Faktor geben, der den Anforderungen der Nutzenden gerecht wird.
Als Entwickler nutzen Sie auch viele andere Anwendungen und Geräte. In dieser Hinsicht sind Sie die Nutzer, die sich auf all diese Systeme verlassen, um „einfach zu funktionieren“. Im Gegenzug verlassen Sie sich auf unzählige Entwickler, die ihr Bestes geben, damit ihre Apps und Geräte funktionieren. Um das wieder rückgängig zu machen, müssen auch Sie als Entwickler diesem Vertrauen gerecht werden. Ihr erstes Ziel sollte also immer darin bestehen, funktionierende Software zu liefern und für Ihre Nutzenden zu bedienen. Dies gilt auch für die von Ihnen geschriebenen Tests, um die Anwendungsqualität sicherzustellen. Kent C. Dodds fasst dies in seinem Beitrag Static vs Unit vs. Integration vs E2E Testing for Frontend Apps sehr gut zusammen:
Je mehr Ihre Tests der Art und Weise ähneln, wie Ihre Software verwendet wird, desto mehr Vertrauen können sie Ihnen geben.
von Kent C. Dodds
Kent beschreibt es darin, das Vertrauen in Tests zu gewinnen. Je näher Sie sich den Nutzern stellen, indem Sie einen passenden Testtyp auswählen, desto mehr können Sie sich darauf verlassen, dass Ihre Tests aussagekräftige Ergebnisse liefern. Mit anderen Worten, je höher Sie die Pyramide erklimmen, desto selbstbewusster werden Sie. Aber was ist die Pyramide?
Teststrategien festlegen: So wählst du eine Teststrategie aus
Bestimmen Sie zuerst, welche Teile der Anforderungen überprüft werden müssen, um sicherzustellen, dass sie erfüllt werden. Finden Sie heraus, welche Testtypen Sie verwenden sollten und mit welchem Detailgrad Sie die höchste Zuverlässigkeit erreichen können, während eine effiziente Kostenstruktur beibehalten wird. Viele Entwickler gehen diesem Thema anhand von Analogien vor. Im Folgenden sind die häufigsten aufgeführt, beginnend mit dem bekannten Klassiker.
Der Klassiker: Die Testpyramide
Wenn Sie nach Teststrategien suchen, werden Sie wahrscheinlich die Testautomatisierungspyramide als erste Analogie sehen. Mike Cohn stellte dieses Konzept in seinem Buch „Succeeding with Agile“ vor. Später baute Martin Fowler das Konzept in seinem Artikel Practical Test Pyramid auf. Sie können die Pyramide so visuell darstellen:
Wie in dieser Zeichnung dargestellt, besteht die Testpyramide aus drei Schichten:
Einheit: Sie befinden sich auf der Basisschicht der Pyramide, weil sie schnell ausgeführt und einfach zu pflegen sind. Sie sind isoliert und zielen auf die kleinsten Testeinheiten ab. Sehen Sie sich zum Beispiel einen typischen Einheitentest für ein sehr kleines Produkt an.
Integration. Diese Tests befinden sich mitten in der Pyramide, da sie zwar eine akzeptable Ausführungsgeschwindigkeit haben, Sie aber näher am Nutzer sind als Einheitentests. Ein Beispiel für einen Integrationstest ist ein API-Test. Sie können auch Komponententests nach diesem Typ klassifizieren.
E2E-Tests (auch UI-Tests genannt). Bei diesen Tests werden echte Nutzer und deren Interaktion simuliert. Solche Tests benötigen mehr Zeit für die Ausführung und sind daher teurer. Sie befinden sich ganz oben auf der Pyramide.
Konfidenz versus Ressourcen
Wie bereits kurz erwähnt, ist die Reihenfolge der Layer kein Zufall. Hier werden die Prioritäten und die entsprechenden Kosten aufgeführt. Dadurch erhalten Sie ein klares Bild davon, wie viele Tests für jede Ebene geschrieben werden sollten. Sie haben dies bereits in der Definition der Testtypen gesehen.
Da E2E-Tests Ihren Nutzern am nächsten sind, können Sie sicher sein, dass Ihre Anwendung wie vorgesehen funktioniert. Sie erfordern jedoch einen vollständigen Anwendungs-Stack und einen simulierten Nutzer, sodass sie möglicherweise auch die teuersten sind. Die Zuversicht steht also in direktem Wettbewerb mit den Ressourcen, die Sie zum Ausführen der Tests benötigen.
Die Pyramide versucht, dieses Problem zu lösen, indem Sie sich mehr auf Unittests konzentrieren und die Fälle, die von E2E-Tests abgedeckt werden, streng priorisieren. Zum Beispiel die wichtigsten User Journeys oder die Orte, an denen am häufigsten Fehler auftreten. Wie Martin Fowler betont, sind die beiden wichtigsten Punkte in der Cohns Pyramide wie folgt:
- Tests mit unterschiedlichem Detaillierungsgrad schreiben.
- Je höher das Level ist, desto weniger Tests sollten durchgeführt werden.
Pyramide entwickelt! Adaptionen der Testpyramiden
Seit mehreren Jahren dreht sich die Diskussion um die Pyramide. Die Pyramide scheint die Teststrategien zu vereinfachen, und es fehlen viele Testtypen und passt nicht mehr zu allen realen Projekten. Daher kann es irreführend sein. Ist die Pyramide aus der Form gefallen? Guillermo Rauch hat eine Meinung dazu:
Tests schreiben aber nicht zu viele. Hauptsächlich Integration.
von Guillermo Rauch
Dies ist eines der am häufigsten zitierten Zitate zu diesem Thema. Schauen wir es uns einmal genauer an:
- „Tests schreiben“. Es stärkt nicht nur Vertrauen, sondern spart auch Zeit bei der Wartung.
- „Nicht zu viele“. Eine Abdeckung von 100% ist nicht immer gut, da Ihre Tests dann nicht priorisiert werden und viel Wartung erforderlich ist.
- „Mostly integration“. Auch hier liegt der Schwerpunkt auf den Integrationstests: Sie sind am profitabelsten, da sie täglich ein hohes Konfidenzniveau bieten und gleichzeitig eine angemessene Ausführungszeit einhalten können.
Das lässt Sie über die Testpyramide nachdenken und sich auf Integrationstests konzentrieren. In den letzten Jahren wurden viele Anpassungen vorgeschlagen. Sehen wir uns daher die häufigsten an.
Testdiamant
Bei der ersten Anpassung wird die Überbetonung der Einheitentests beseitigt, wie in der Testpyramide zu sehen. Angenommen, Sie haben eine Abdeckung von 100% bei Einheitentests erreicht. Bei der nächsten Refaktorierung müssen Sie jedoch viele dieser Einheitentests aktualisieren. Möglicherweise sind Sie versucht, diese zu überspringen. Also roden sie.
Daraus und zusammen mit dem verstärkten Fokus auf Integrationstests können sich folgende Formen ergeben:
Eine Pyramide entwickelt sich zu einem Diamanten. Sie können die vorherigen drei Ebenen sehen, aber in einer anderen Größe. Die Einheitsschicht wurde ausgeschnitten:
- Einheit: Schreiben Sie Einheitentests so, wie Sie sie zuvor definiert haben. Da sie jedoch dazu neigen, nur die kritischsten Fälle abzudecken, zu priorisieren und abzudecken.
- Integration. Integrationstests, bei denen die Kombination einzelner Einheiten getestet wird.
- E2E: Diese Ebene verarbeitet die UI-Tests ähnlich wie die Testpyramide. Schreiben Sie nur E2E-Tests für die kritischsten Testfälle.
Honeycomb wird getestet
Es gibt eine weitere Anpassung von Spotify, die dem Testdiamanten ähnelt, aber weiter speziell auf Mikrodienste-basierte Softwaresysteme zugeschnitten ist. Die Honigwabe ist eine weitere visuelle Analogie für den Detaillierungsgrad, den Umfang und die Anzahl der Tests, die für ein mikrodienstbasiertes Softwaresystem geschrieben werden sollen. Aufgrund ihrer geringen Größe liegt die größte Komplexität bei einem Mikrodienst nicht im Dienst selbst, sondern in der Art und Weise, wie er mit anderen interagiert. Eine Teststrategie für einen Mikrodienst sollte sich daher in erster Linie auf Integrationstests konzentrieren.
Diese Form erinnert an eine Honigwabe, demnach auch der Name. Sie besteht aus folgenden Ebenen:
- Integrierte Tests: Der Artikel von Spotify verwendet ein Zitat von J. B. Rainsberger, um diese Ebene zu definieren: „Ein Test, der entweder bestanden wird oder fehlschlägt, je nachdem, ob ein anderes System korrekt ist.“ Solche Tests haben externe Abhängigkeiten, die Sie berücksichtigen müssen. Im Gegenteil, Ihr System könnte eine Abhängigkeit sein, die andere Systeme beeinträchtigt. Ähnlich wie bei E2E-Tests in anderen Analogien sollten diese Tests nur für die wichtigsten Fälle eingesetzt werden.
- Integrationstests: Ähnlich wie bei anderen Anpassungen sollten Sie sich auf diese Ebene konzentrieren. Sie enthält Tests, die die Richtigkeit Ihres Dienstes isolierter prüfen, aber immer noch in Kombination mit anderen Diensten. Die Tests umfassen also auch einige andere Systeme und konzentrieren sich auf die Interaktionspunkte, beispielsweise über API-Tests.
- Tests von Implementierungsdetails: Diese Tests ähneln Unittests – Tests, die sich auf Teile des Codes konzentrieren, die natürlich isoliert sind und daher eine eigene interne Komplexität haben.
Weitere Informationen zu dieser Teststrategie finden Sie im Beitrag zum Vergleich der Testpyramide mit der Honigwabe (Honeycomb) von Martin Fowler und im Originalartikel von Spotify.
Testpokal
Sie sehen bereits, dass der Fokus immer wieder auf Integrationstests liegt. Bei einer anderen Art, auf die Sie im vorherigen Artikel gestoßen sind, handelt es sich jedoch nicht um theoretische Tests, sondern um einen wichtigen Aspekt, den Sie bei einer Teststrategie berücksichtigen sollten. In der Testpyramide und in den meisten Anpassungen, die Sie bisher gesehen haben, fehlt eine statische Analyse. Es gibt die Anpassung an den Testpokal, die die statische Analyse berücksichtigt, ohne den Fokus auf Integrationstests zu legen. Die Testtrophäe basiert auf einem früheren Zitat von Guillermo Rauch und wurde von Kent C. Tipps:
Der Test-Pokal ist eine Analogie, die den Detaillierungsgrad von Tests etwas anders darstellt. Sie besteht aus vier Schichten:
- Statische Analyse: Die Funktion spielt in dieser Analogie eine wichtige Rolle. Sie können Tippfehler, Stilfehler und andere Fehler erkennen, indem Sie einfach die bereits beschriebenen Schritte zur Fehlerbehebung ausführen.
- Einheitentests: Sie stellen sicher, dass Ihre kleinste Einheit angemessen getestet wird, aber die Testtrophäe hebt sie nicht im gleichen Maß hervor wie die Testpyramide.
- Integration. Dies ist das Hauptaugenmerk, da es die Kosten und das höhere Vertrauen auf die beste Weise ausgleicht, wie bei anderen Anpassungen.
- UI-Tests Einschließlich E2E- und visueller Tests sind sie ganz oben auf der Testtrophäe, ähnlich wie ihre Rolle in der Testpyramide.
Weitere Informationen zur Testtrophäe findest du im Blogpost von Kent C. Dodds zu diesem Thema.
Einige UI-orientierte Ansätze
Das ist alles in Ordnung, aber egal, wie du deine Strategie „Pyramide“, „Wabe“ oder „Raute“ benennst, es fehlt immer noch etwas. Die Testautomatisierung ist zwar wertvoll, aber dennoch unverzichtbar, auch manuelle Tests. Automatisierte Tests sollten Routineaufgaben entlasten und das Engineering-Team für die Qualitätssicherung freisetzen, damit es sich auf wichtige Bereiche konzentrieren kann. Anstatt manuelle Tests zu ersetzen, sollte die Automatisierung sie ergänzen. Gibt es eine Möglichkeit, manuelle Tests in Automatisierung zu integrieren, um optimale Ergebnisse zu erzielen?
Eiswaffel und Testkrabbe
Tatsächlich gibt es zwei Anpassungen der Testpyramide, die sich mehr auf diese UI-fokussierten Testmethoden konzentrieren. Beide bieten den Vorteil einer hohen Zuverlässigkeit, sind aber aufgrund der langsameren Testausführung auch kostspieliger.
Das erste, der Testeiskegel, sieht aus wie die Pyramide umgekehrt. Ohne den manuellen Testschritt wird es auch als Testpizza bezeichnet.
Der Eiskegel konzentriert sich stärker auf manuelle oder UI-Tests und am wenigsten auf Einheitentests. Sie nimmt häufig Gestalt an, wenn Entwickelnde mit nur wenigen Gedanken über die Teststrategie begannen, zu arbeiten. Der Eiscode gilt zu Recht als Anti-Muster. Er ist kostspielig in Bezug auf Ressourcen und manuelle Arbeit.
Die Testkrabbe ähnelt dem Testeiskegel, allerdings mit Schwerpunkt auf E2E und visuellen Tests:
Diese Teststrategie umfasst einen weiteren Aspekt: Sie prüft, ob Ihre Anwendung funktioniert und gut aussieht. Das Testkrebs hebt die Bedeutung von visuellen Tests hervor, die im vorherigen Artikel beschrieben wurden. Integrationstests, die in Komponenten- und API-Tests unterteilt sind, gehen im Hintergrund weiter. Unittests spielen hier eine noch untergeordnete Rolle. Weitere Details zu dieser Teststrategie finden Sie in diesem Artikel über die Testkrabbe.
Diese beiden Teststrategien sind zwar teurer, haben aber ihre Bedeutung: beispielsweise in kleineren Projekten, in denen weniger Tests erforderlich sind oder weniger Komplexität abgedeckt werden muss. In diesem Fall könnte eine umfassende Teststrategie, die sich auf Integrationstests konzentriert, Over-Engineering sein.
Obwohl diese beiden Teststrategien kostspieliger sind, haben sie ihren Platz beispielsweise in kleineren Projekten, die weniger Tests erfordern und nicht viel Komplexität abdecken müssen. In diesem Fall kann eine umfassende Teststrategie, die sich auf Integrationstests konzentriert, unnötig komplex sein.
Praktische Ratschläge: Legen wir eine Strategie fest!
Du hast jetzt die gängigsten Teststrategien kennengelernt. Du hast mit dem Klassiker – der Testpyramide – angefangen und die vielen Adaptionen des Klassikers kennengelernt. Jetzt müssen Sie diese für Ihr Produkt bewerten und entscheiden, was für Ihr Projekt am besten geeignet ist. Die Antwort auf diese Frage sollte mit dem Lieblingswort „Das kommt darauf“ beginnen. Das macht sie aber nicht weniger genau.
Die Wahl der am besten geeigneten Teststrategie aus den beschriebenen – und selbst den ausgelassenen – hängt von Ihrer Anwendung ab. Sie sollte Ihre Architektur, Ihre Anforderungen und zu guter Letzt Ihre Nutzenden und deren Anforderungen widerspiegeln. All dies kann sich von Anwendung zu Anwendung unterscheiden. Das ist völlig normal. Denken Sie daran, dass Ihr wichtigstes Ziel darin besteht, Ihren Nutzenden zu dienen, und nicht die Definition eines Lehrbuchs.
Meistens ist es schwierig, Tests in der Praxis voneinander zu trennen und individuell zu definieren. Selbst Martin Fowler betont selbst den positiven Aspekt unterschiedlicher Definitionen, z. B. im Fall von Einheitentests. Justin Searls sagt in seinem Tweet richtig:
[...] ausdrucksstarke Tests schreiben, die klare Grenzen festlegen, schnell und zuverlässig ausgeführt werden und nur aus aussagekräftigen Gründen fehlschlagen.
von Justin Searls
Konzentrieren Sie sich auf die Tests, die tatsächliche Fehler melden, die die Nutzenden stoßen könnten, und lassen Sie sich nicht von Ihrem Ziel ablenken. Die Tests sollten dem Nutzer zugutekommen und nicht nur eine Abdeckung von 100% bieten oder zu einer Debatte darüber führen, welcher Prozentsatz welcher Testart geschrieben werden sollte.
Konzentrieren Sie sich auf Tests, die reale Fehler melden, auf die Ihre Nutzenden stoßen könnten, und die nicht von Ihrem Ziel abgelenkt werden. Die Tests sollten dem Nutzer zugutekommen und nicht nur eine 100% ige Abdeckung bieten oder eine Debatte darüber anregen, wie viel Prozent eines bestimmten Testtyps Sie schreiben sollten.