Testen verstehen

Worum es geht

Tests schreiben ist nicht mehr der Engpass. Ein Coding Agent erzeugt in Sekunden mehr Tests, als du an einem Tag schreiben würdest. Sie sind grün, und die Code Coverage sieht gut aus. Aber prüfen sie auch, was deine Software tun soll, oder bestätigen sie nur, was der Code gerade tut, einschließlich seiner Fehler?

Diese Frage kann dir kein Werkzeug abnehmen. Um sie zu beantworten, musst du verstehen, was einen guten Test ausmacht: woher er seine Erwartung nimmt, wie viel vom System er umfasst, wann er eine Abhängigkeit ersetzen darf und was ein grüner Balken wirklich bedeutet.

Darum schreibst du in dieser Schulung keinen Code, du liest ihn. Sebastian erklärt dir die Begriffe und Prinzipien und zeigt sie an Beispielen, und du wendest sie an echten Tests an, darunter viele, die ein Agent geschrieben hat. Die Beispiele sind in PHP mit PHPUnit, das Gelernte nimmst du in jede Sprache mit.

So arbeitest du in dieser Schulung

Jede Sitzung folgt demselben Rhythmus:

• Erklärung. Ein Begriff oder Prinzip, an einem kleinen Beispiel.
• Vorführung. Das Prinzip an lauffähigem Code, an dem Tests rot und grün werden.
• Beurteilungsübung. In Breakout-Räumen beurteilst du mit anderen vorgelegte Tests anhand eines Bogens, viele davon von einem Agenten erzeugt.
• Diskussion. Die Gruppen vergleichen ihre Urteile und begründen, wo sie voneinander abweichen.

Über allen Sitzungen steht die Frage: „Was weißt du, wenn dieser Test grün ist?“ Die Beispiele stammen aus einem kleinen Warenkorb in PHP, und am Ende jeder Sitzung schauen wir kurz über PHP hinaus: wie dasselbe Konzept in anderen Sprachen und Werkzeugen heißt. Die Kriterien aller Sitzungen wachsen zu einer Checkliste zusammen, die du in der letzten Sitzung auf eine vollständige generierte Testsuite anwendest.

Ablauf

1. 1

   Sitzung 1: Was ein Test aussagt

   Was weißt du, wenn ein Test grün ist, und was nicht?

   • Ein Test als aufgeschriebene, jederzeit wiederholbare Erwartung, und sein Aufbau: Arrange, Act, Assert oder Given, When, Then
   • Das Orakel: Kommt die erwartete Antwort aus der Anforderung oder aus dem Code? Ein Test, der sie aus dem Code nimmt, bestätigt auch dessen Fehler
   • Testfälle finden: Äquivalenzklassen, Grenzwerte, Fehlerfälle
   • Fehlschlag oder Fehler: Die Erwartung ist verletzt, oder der Test konnte nicht ausgeführt werden
   • Was ein grüner Test nicht sagt

   Ergebnis: Testfälle und Grenzfälle für eine Anforderung, bestimmt, bevor du die Tests dazu liest, und für jeden Test die Antwort darauf, woher er seine Erwartung nimmt

2. 2

   Sitzung 2: Eigenschaften guter Tests: F.I.R.S.T.

   Woran erkennst du einen guten Test, bevor er dich enttäuscht?

   • Fast: Ein langsamer Test läuft seltener, als er sollte
   • Isolated: Ein Test hängt nicht von anderen Tests und ihrer Reihenfolge ab
   • Repeatable: gleiches Ergebnis auf jedem Rechner, zu jeder Uhrzeit, ohne Netz
   • Self-Validating: Der Test entscheidet selbst über Erfolg und Misserfolg, niemand muss eine Ausgabe lesen
   • Timely: Wann entsteht ein Test, und was bedeutet es, wenn ein Agent ihn nach dem Code schreibt?
   • Typische Verstöße in generierten Tests: echte Uhrzeit, Zufall, Netzwerk, Assertions ohne Aussage

   Ergebnis: Zehn vorgelegte Tests, beurteilt danach, gegen welches Prinzip jeder verstößt und was das im Alltag zur Folge hätte

3. 3

   Sitzung 3: Der Lebenszyklus eines Tests

   Was geschieht vor, während und nach einem Test, und wie lange lebt er?

   • Im Testlauf: Fixture aufbauen, ausführen, prüfen, aufräumen (Four-Phase Test)
   • Frische und geteilte Fixtures, setUp() und tearDown(), und was ein Test-Framework isoliert und was nicht
   • Geteilter Zustand als häufigste Ursache für Tests, die mal grün und mal rot sind
   • In der Codebasis: Ein Test entsteht, wird rot, wird angepasst oder gelöscht. Wann ist ein roter Test eine Regression, wann eine geänderte Anforderung?
   • Kurzlebige und langlebige Tests: Ein Sicherheitsnetz für ein Refactoring darf danach weg, eine fachliche Regel bleibt

   Ergebnis: Geteilter Zustand in vorgelegten Tests erkannt, und für jeden Test, den eine geänderte Anforderung des Warenkorbs betrifft, eine begründete Entscheidung: behalten, anpassen oder löschen

4. 4

   Sitzung 4: Test Scope

   Wie viel System gehört in einen Test?

   • Was ist eine Unit? Solitary und Sociable Unit Tests
   • Unit, Integration, End-to-End: was jede Ebene finden kann und was nicht
   • Systemgrenzen wie Datenbank, Dateisystem, Netzwerk und Zeit, und Testgrößen danach, welche davon ein Test berührt: klein, mittel, groß
   • Kosten je Ebene: Laufzeit, Stabilität, Genauigkeit der Fehlermeldung
   • Die Testpyramide als erster Überblick

   Ergebnis: Die Erwartungen an den Bestellvorgang des Warenkorbs, begründet auf Ebenen verteilt, und eine generierte Testsuite, deren Tests nach ihrem tatsächlichen Umfang eingeordnet sind

5. 5

   Sitzung 5: Test Doubles

   Wann ersetzt du eine Abhängigkeit, und wodurch?

   • Warum eine Abhängigkeit ersetzt wird: Langsamkeit, Nichtdeterminismus, Seiteneffekte, Unerreichbarkeit
   • Dummy, Stub, Spy, Mock und Fake, und ob ein Test Zustand oder Kommunikation prüft
   • Wann ein Double täuscht: Es antwortet so, wie du glaubst, dass die echte Abhängigkeit antwortet
   • Nur eigene Schnittstellen ersetzen und keine Wertobjekte
   • Generierte Tests ersetzen oft alles: Was prüfen sie dann noch?

   Ergebnis: Jedes Test Double in vorgelegten Tests benannt, mit einer Entscheidung, ob es das richtige ist, ob es überhaupt nötig ist und was es verdeckt

6. 6

   Sitzung 6: Code Coverage und das Gesamtbild

   Was misst Code Coverage, und was nicht?

   • Line, Branch und Path Coverage
   • Coverage misst Ausführung, nicht Prüfung: Ein Test ohne Assertion erreicht 100 %, und generierte Tests erreichen hohe Werte ohne Aussage
   • Coverage als Lückensucher: Eine nicht ausgeführte Zeile ist eine Frage, kein Ziel
   • Ausblick: Mutation Testing misst, ob Tests prüfen
   • Die Checkliste: Orakel, F.I.R.S.T., Lebensdauer, Umfang, Doubles, Coverage

   Ergebnis: Eine vollständige generierte Testsuite für den Warenkorb, mit der Checkliste beurteilt: welche Tests du behältst, welche du änderst und welche du löschst

Für wen

• Entwicklerinnen und Entwickler, die Tests von Coding Agents schreiben lassen und beurteilen wollen, ob sie etwas taugen
• Alle, die schon Tests schreiben, aber die Begriffe und Prinzipien dahinter nie systematisch gelernt haben
• Tech Leads, Reviewerinnen und Reviewer, die im Pull Request über Tests urteilen
• Entwicklerinnen und Entwickler, die in anderen Sprachen als PHP arbeiten: Die Konzepte sind sprachunabhängig

Voraussetzungen

• Erfahrung in der Softwareentwicklung mit einer objektorientierten Programmiersprache
• Vorwissen im Testen ist nicht nötig
• Eine Entwicklungsumgebung brauchst du nicht: Du liest und beurteilst Code, du schreibst keinen

Das nimmst du mit

• Du bestimmst Testfälle und Grenzfälle für eine Anforderung systematisch
• Du erkennst, wann ein Test seine Erwartung aus dem Code statt aus der Anforderung nimmt
• Du beurteilst Tests nach den F.I.R.S.T.-Prinzipien und benennst, was einem Test fehlt
• Du ordnest Tests nach ihrem Umfang ein und weißt, was jede Ebene finden kann
• Du unterscheidest Test Doubles und erkennst, wann eines mehr verdeckt als hilft
• Du liest Coverage-Berichte richtig und lässt dich von 100 % nicht täuschen
• Du nimmst eine Checkliste mit, mit der du jeden Test beurteilst, egal ob ein Mensch oder ein Agent ihn geschrieben hat

Verwandte Schulungen

Diese Schulung ist Teil der Lernpfade Einstieg ins Testen, Testvorgaben im Team.