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.
Erwische den Fehler
Kein Erklären: Nova hat echten Code mit einer eingebauten Schwachstelle produziert — du reviewst ihn wie in einem Pull Request, findest den Fehler und nennst den Fix. Erst wenn du den echten Fehler erwischst, verdienst du dein Siegel.
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.