Testpyramide
Dieser Beitrag ist eine Begriffserklärung zur Testpyramide – inklusive Prüfungsfragen und Tags.
In a Nutshell
Die Testpyramide priorisiert viele schnelle und stabile Unit Tests, weniger Integrationstests und wenige End‑to‑End‑Tests, um mit minimalen Kosten maximale Sicherheit zu erreichen. Ziel sind kurze Rückmeldungen in der CI und verlässliche Abdeckung ohne fragiles Übergewicht an UI‑Tests.
Kompakte Fachbeschreibung
Die Testpyramide strukturiert automatisierte Qualitätssicherung in Ebenen nach Kosten, Ausführungszeit und Fehlersuchpräzision.
- Unit‑Ebene: schnell, isoliert, deterministisch; hohe Fehlerlokalisierung; Nutzung von Mocks und Stubs.
- Integrationsebene: echte Komponenteninteraktion (Datenbank, Dateisystem, Netzwerk); oft mit Contract Tests zwischen Diensten.
- E2E‑Ebene: wenige, aber geschäftskritische Nutzerflüsse über UI & Infrastruktur; hohes Vertrauen, höhere Kosten.
Gute Metriken: Code Coverage (als Trend), Mutation Testing (Wirksamkeit), Flaky Rate (Stabilität). Anti‑Muster: Eiscreme‑Kegel (zu viele UI‑Tests), Sanduhr (zu wenige Unit Tests).
Prüfungsrelevante Stichpunkte
- Zielverteilung: ca. 70 % Unit, 20 % Integration, 10 % E2E (kontextabhängig)
- Unit‑Ebene: schnell, isoliert, deterministisch, hohe Fehlerlokalisierung
- Integration: echte Schnittstellen, Testdatenmanagement, Container‑Services
- E2E: wenige kritische Flows, reale Umgebung nahe Produktion
- Contract Tests für Service‑Grenzen (Microservices)
- CI‑Pipeline: schnelle Feedbackstufen, parallele Ausführung, Artefaktversionierung
- Metriken: Coverage, Mutation Score, Build‑Zeit, Flaky Rate
- Dokumentation: Teststrategie, Testfallkatalog, Risikomatrix
Kernkomponenten
- Testebenen (Unit, Integration, E2E)
- Testdoubles (Mock, Stub, Fake, Spy)
- Testdatenstrategie (Factories, Fixtures, Seed‑Daten, Reset)
- Infrastruktur im Test (Datenbank‑Container, Message‑Broker, Sandbox)
- Contract Testing (konsumentengetrieben, Versionierung)
- Testausführung (CI‑Stages, schnelles Gate auf Unit‑Ebene)
- Stabilität (Eliminierung von Flaky Tests, Zeit/Zufall kontrollieren)
- Abdeckung & Wirksamkeit (Coverage, Mutation Testing, Risikoabdeckung)
- Selektives E2E (kritische Pfade, Smoke Suite, visuelle Regression sparsam)
- Wartung (Refactoring, gemeinsame Hilfsbibliotheken, Namenskonventionen)
Praxisbeispiel (Bestellservice)
Unit‑Ebene:
- Arrange: Product mit Preis, DiscountPolicy Mock liefert 10 % Rabatt
- Act: OrderService.totalForBasket()
- Assert: erwarteter Betrag = berechneter Betrag (keine DB‑Zugriffe)
Integration‑Ebene:
- Arrange: reale DB im Container, Repository speichert/liest Order
- Act: OrderRepository.save() + OrderRepository.findById()
- Assert: gespeicherte Felder identisch, Transaktion rollt zurück
E2E‑Ebene:
- Arrange: Anwendung mit Browserautomatisierung starten
- Act: Nutzer legt Artikel in Warenkorb, geht zur Kasse, klickt "Bestellung abschließen"
- Assert: Bestellbestätigung sichtbar, DB‑Eintrag vorhanden, Event im Message Broker
Vorteile und Nachteile
Vorteile
- Kurze Feedbackzeiten
- Hohe Fehlerlokalisierung
- Robuste Pipeline
- Geringere Wartungskosten
- Bessere Planbarkeit
- Höhere Releasefrequenz
Nachteile
- Initialer Infrastrukturaufbau
- Pflege von Testdoubles & Fixtures
- Potenziell blinde Flecken bei falscher Verteilung
- E2E bleibt fragiler
Typische Prüfungsfragen (mit Kurzantwort)
- Warum ist die Testpyramide wirtschaftlich sinnvoll? Viele günstige Unit Tests fangen die meisten Defekte früh ab; teure E2E Tests werden auf kritische Flows begrenzt.
- Woran erkennt man zu viele UI Tests? Lange Builds, hohe Flaky Rate, häufige false negatives, schwierige Fehlerlokalisierung (Eiscreme‑Kegel).
- Wozu Contract Tests bei Microservices? Stabilisieren Schnittstellenbeziehungen, prüfen Kompatibilität unabhängig vom Gesamtsystem.
- Wie verhindert man Flaky Tests? Zeit/Zufall kontrollieren, externe Abhängigkeiten mocken/kapseln, saubere Isolation, deterministische Daten.
- Rolle von Mutation Testing? Prüft, ob Tests logisch wirksam sind (nicht nur Zeilen berühren) → bessere Aussage als reine Coverage.