azena proof
Du baust ein Sicherheitsnetz aus Tests, das dir erlaubt, schnell zu ändern, ohne ständig Dinge kaputtzumachen. Du verstehst die Test-Pyramide, schreibst gute Unit- und E2E-Tests (mit KI als Co-Autor, den du prüfst), arbeitest test-getrieben, liest Coverage richtig und machst Tests zum CI-Gate. Tempo durch Vertrauen statt durch Hoffnung.
Was du danach kannst
- Verstehen, warum Tests Tempo ermöglichen (Sicherheitsnetz, nicht Bürokratie)
- Die Test-Pyramide anwenden (viele Unit, weniger Integration, wenige E2E)
- Gute Tests schreiben (schnell, isoliert, deterministisch, Verhalten statt Implementierung)
- Test-getrieben arbeiten (Red-Green-Refactor) und KI Tests schreiben lassen — geprüft
- Tests als CI-Gate aufsetzen und Coverage richtig interpretieren
Das Curriculum
19 Lektionen · Schritt für Schritt
- 01
Warum testen — Tempo durch Vertrauen
9′Tests sind kein Bremsklotz, sondern das Sicherheitsnetz, das schnelles Ändern erst erlaubt.
- 02
Die Test-Pyramide — viele kleine, wenige große
8′Nicht alle Tests sind gleich. Die Pyramide sagt dir, wo du wie viele brauchst.
- 03
Was einen guten Test ausmacht
8′Ein schlechter Test ist schlimmer als keiner. Vier Eigenschaften trennen gut von Last.
- 04
TDD — erst der Test, dann der Code
8′Test-Driven Development dreht die Reihenfolge um — und schärft dabei dein Design.
- 05
Unit-Tests mit KI schreiben — schnell, aber geprüft
8′Die KI generiert Tests in Sekunden. Dein Job: sicherstellen, dass sie das Richtige prüfen.
- 06
Verhalten testen, nicht Implementierung
8′Der wichtigste Unterschied zwischen Tests, die helfen, und Tests, die nerven.
- 07
KI-Funktionen testen — wenn dieselbe Eingabe verschiedene Ausgaben liefert
9′Eine KI-Ausgabe ist nicht-deterministisch — `assertEquals` ist nutzlos. Du prüfst in drei Ebenen: deterministisch, auf Eigenschaften, und per LLM-Richter.
- 08
Integration & E2E — die echten Wege absichern
8′Manche Fehler tauchen nur auf, wenn Teile zusammenspielen. Dafür gibt es die oberen Ebenen.
- 09
Mocks, Fakes & Test-Daten — wann, und wann nicht
7′Test-Doubles ersetzen echte Abhängigkeiten — mächtig, aber leicht überdosiert.
- 10
Coverage richtig lesen — Werkzeug, nicht Ziel
7′100% Coverage beweist nicht, dass dein Code funktioniert. So nutzt du die Zahl richtig.
- 11
Flaky Tests bekämpfen — verlässlich statt Zufall
8′Ein Test, der mal grün, mal rot ist, vergiftet das ganze Netz. So machst du Tests verlässlich.
- 12
Testbarkeit by Design — Code, der sich leicht testen lässt
8′Schwer zu testender Code ist meist schlecht entworfener Code. Testbarkeit ist eine Design-Eigenschaft.
- 13
Snapshot- & Visual-Regression-Tests — UI-Änderungen sichtbar machen
7′Manche Regressionen sieht man nur — verschobene Pixel, kaputtes Layout. Dafür gibt es eigene Tests.
- 14
Performance- & Lasttests — hält es unter Druck
8′Funktioniert ≠ funktioniert schnell genug, auch mit tausend gleichzeitigen Nutzern. Das misst man getrennt.
- 15
Accessibility-Tests — automatisiert prüfen, ob es für alle funktioniert
8′Barrierefreiheit ist eine Qualitätseigenschaft, die du testen kannst — vieles automatisiert, der Rest gezielt manuell.
- 16
Contract-Tests — Anbieter & Consumer bleiben kompatibel
8′Sobald zwei Dienste über eine API reden, kann der eine den anderen brechen, ohne es zu merken. Contract-Tests fangen genau das.
- 17
Property-based & Fuzz-Testing — die KI erfindet die fiesen Eingaben
8′Du testest die drei Fälle, die dir einfallen. Diese Techniken werfen tausende Eingaben gegen deinen Code, an die du nie gedacht hast.
- 18
Exploratives Testen & QA-Mindset — was Automatisierung nicht findet
8′Automatisierte Tests prüfen, was du erwartet hast. Die teuersten Bugs lauern dort, wo du gar nicht hingeschaut hast — die findest du nur von Hand, aber strukturiert.
- 19
Tests als CI-Gate + KI als QA-Reviewer
8′Tests entfalten ihre Kraft erst automatisiert — als Wächter bei jedem Push.
Was du baust
Echte Artefakte, keine Theorie
Eine Funktion test-getrieben bauen (TDD)
Ergebnis: Die Funktion + ihre Tests (grün), entstanden im Red-Green-Refactor-Zyklus.
Einen kritischen Flow per E2E absichern
Ergebnis: Ein grüner, stabiler E2E-Test für einen kritischen Flow + ein Satz zu vermiedenen Flaky-Ursachen.
Capstone: Ein Testnetz + CI-Gate für ein echtes Feature
Ergebnis: Ein ausgewogenes Testnetz (Pyramide) + grünes CI-Gate + die QA-Review-Findings, kurz adressiert.
Belege & Quellen
Jede Aussage ist belegt — echte, geprüfte Quellen statt Behauptungen.
Reinschnuppern
Gratis-VorschauGO vs. NO-GO — ein echtes Beispiel aus dem Track.
Wie der Track läuft
Mit Nova als Mentor
Dein KI-Mentor erklärt jedes Konzept, gibt dir fertige Claude-Code-Prompts und hilft bei jeder Frage.
Geprüftes Siegel
Beschreib Nova, wie du ein echtes Feature absicherst: warum Tests dir Tempo geben, wie du die Pyramide aufteilst, wie du test-getrieben mit KI arbeitest (und die KI-Tests prüfst — Verhalten statt Implementierung), wofür du E2E einsetzt und Flakiness vermeidest, wie du Coverage interpretierst (Werkzeug, nicht Ziel) und warum die Tests als CI-Gate laufen.
In deinem Tempo
Rund 142 Minuten Kerninhalt — plus deine eigenen Projekte. Jederzeit pausierbar.
Fehler, die du vermeidest
- Tests als Bürokratie sehen statt als Sicherheitsnetz, das Tempo erst ermöglicht.
- Die Pyramide auf den Kopf stellen (Eistüte): viele langsame, flaky E2E-Tests, kaum Unit-Tests.
- Implementierung statt Verhalten testen — die Tests brechen bei jedem Refactor.
- KI-Tests ungeprüft übernehmen (sie spiegeln Bugs / assertieren Sinnloses).
- Alles mocken — am Ende testet man die Mocks, nicht den Code.
- Coverage als Ziel jagen statt als Diagnose nutzen (100% ohne sinnvolle Asserts).
Bereit für azena proof?
250 Token · 19 Lektionen · von der KI geprüft.