Was Tests und TDD sind - einfach erklärt

Was ein Test ist, einfach erklärt

Du hast einen IKEA-Schrank zusammengebaut. Die Tür geht auf, die Regale stehen - sieht top aus, kannst du glatt in die Story packen. Eine Woche später schraubst du ein neues Regal an und verkantest dabei aus Versehen die Tür. Und du siehst es nicht. Du siehst es einen Monat später - wenn dir die Tür feierlich auf den Fuß kracht.

Damit das nicht passiert, gibt es Tests. Ein Test Test - ein kleines Prüf-Programm. Es startet selbst deinen Code, füttert ihn mit Daten und prüft, ob das Ergebnis stimmt. Wenn etwas nicht passt, schreit es laut „kaputt“. ist ein Roboter, der nach jeder deiner Änderungen den ganzen Schrank abgeht und an jeder Tür rüttelt: geht sie auf? geht sie zu? ist sie nicht verkantet? Gerüttelt - und sofort gemeldet. „Alles okay“ oder „hier ist was abgefallen, repariere“.

Und TDD ist einfach eine Angewohnheit. Erst den Prüf-Roboter rufen, und erst danach bauen.

Wozu Tests einem Vibecoder gut sind

Du bist Vibecoder. Tests schreibst du nicht von Hand - die schreibt der Agent. Aber wenn du verstehst, wozu sie überhaupt da sind, kassierst du gleich vier nette Boni:

• du hörst auf, Angst vorm Anfassen des Codes zu haben - der Roboter sagt dir selbst, wenn etwas verrutscht ist;
• du fängst Bugs bevor sie der User bemerkt (und erst recht der Auftraggeber);
• du kannst dem Agenten entspannt sagen „schreib das schöner um“ - die Tests fangen dich auf;
• und endlich verstehst du, warum der Agent „erst eine Prüfung schreibt, die fällt“. Das ist kein Bug. Das ist Methode.

Der Unterschied zwischen „meine Seite geht ständig irgendwo kaputt, und ich check nicht wo“ und „ich ändere was ich will und schlafe ruhig“ kommt meist auf ein Wort raus: Tests.

Der TDD-Zyklus: rot, grün, aufhübschen

Bittest du den Agenten, nach TDD zu arbeiten, knallt er nicht einfach planlos Code raus. Er folgt einem klaren Zyklus. Hier ist er, ohne Fachchinesisch.

Schritt 1. Wir beschreiben, was wir wollen

Zuerst formuliert der Agent die Aufgabe aus Sicht des Users: „Ich als Käufer will Produkte nach Sinn suchen, um das Richtige auch ohne exakte Worte zu finden“. Das nennt man User Journey User Journey - eine kurze Geschichte „wer will was und warum“. Hilft zu verstehen, was überhaupt geprüft werden muss, noch bevor Code geschrieben wird. . Daraus wird sofort klar, was zu prüfen ist.

Schritt 2. Wir schreiben den Test - und er fällt ABSICHTLICH

Jetzt wird es seltsam. Der Agent schreibt die Prüfung vor dem Code. Klar, dass sie sofort fällt - es gibt ja noch keinen Code! Genau das ist die rote RED (rot) - der Zustand, wenn der Test geschrieben, gestartet und gefallen ist. Das ist normal und Pflicht: so stellen wir sicher, dass der Test überhaupt funktioniert und wirklich das Richtige prüft. Phase.

Schritt 3. Wir schreiben das Minimum an Code, damit der Test grün wird

Jetzt schreibt der Agent genau so viel Code, dass der Test durchläuft. Keine Zeile mehr. Der Test wird von rot zu grün GREEN (grün) - der Test wurde nach dem Schreiben des Codes gestartet und ist durchgelaufen. Heißt: das gewünschte Verhalten funktioniert wirklich. . Der Roboter ist zufrieden. Du auch.

Schritt 4. Wir hübschen auf (Refactoring)

Der Code läuft, aber sieht, sagen wir mal nett, ziemlich wild aus. Jetzt darfst du ihn aufhübschen - Dopplungen rauswerfen, verständlicher benennen. Und nach jedem Schritt die Tests durchjagen: solange sie grün sind, hast du nichts kaputtgemacht.

Arten von Tests: Unit, Integration, E2E

Tests gibt es in drei „Größen“ - vom Kleinen zum Großen. Ein guter Agent deckt alle drei ab, nicht nur seinen Liebling.

Guter Test gegen schlechten: wie du sie unterscheidest

Die häufigste Falle: ein Test ist irgendwie da, prüft aber das Falsche. So unterscheidest du einen verlässlichen Roboter von einem dekorativen. Das kommt direkt aus den Regeln des Skills tdd-workflow.

Beispiel aus dem Leben: wie ein Gutscheincode den Warenkorb zerlegt

Du hast einen Online-Shop gebaut. Der Warenkorb rechnet die Summe - läuft. Eine Woche später bittest du den Agenten: „füg einen Rabatt-Gutscheincode hinzu“. Er fügt ihn hinzu. Der Code rockt! Du freust dich und schläfst wie ein Baby.

Und am Morgen die Überraschung: nach dem Einbau des Gutscheincodes fängt die normale Summe ohne Rabatt an, mit einem Cent-Fehler gerechnet zu werden. Du hast es nicht gemerkt, weil du nur den Gutscheincode geprüft hast. Dafür hat es der Kunde gemerkt - und eine herzliche Ein-Stern-Bewertung dagelassen.

Mit Tests wäre das nicht passiert. Der Prüf-Roboter hätte nach der Gutschein-Änderung selbst auch den normalen Warenkorb nachgerechnet und geschrien: „hey, hier sind jetzt 99 Euro statt 100, repariere“. In drei Sekunden - vor dem Schlafen, nicht danach.

So bittest du den Agenten, dass er dich absichert:

Füge dem Warenkorb Unterstützung für Rabatt-Gutscheincodes hinzu. Arbeite strikt nach TDD:

Beschreibe zuerst in einfachen Worten, was passieren soll: was gibt der User ein und was soll er sehen.
Schreib die Tests VOR dem Code. Prüf unbedingt auch den normalen Warenkorb ohne Gutscheincode - ich will sicher sein, dass er nicht kaputtgegangen ist.
Starte die Tests und zeig mir, dass der neue Test fällt. Das ist normal, so soll es sein.
Schreib jetzt das Minimum an Code, damit alle Tests grün werden.
Starte die Tests erneut und zeig, dass alles grün ist.
Prüf die Randfälle: leerer Gutscheincode, nicht existierender Gutscheincode, Rabatt größer als die Summe.

Wie du Tests „pro forma“ entlarvst

Manchmal hat es der Agent eilig und tut so, als hätte er getestet. Geh die Checkliste durch - das ist genau der Kern des Skills tdd-workflow.

1. Ist der Test wirklich gefallen? Der Agent hat sofort Grün gezeigt, ohne Rot? Dann prüft der Test vielleicht rein gar nichts.
2. Wurde das Alte mitgelaufen? Ein neues Feature darf nicht kaputtmachen, was lief. Frag direkt: „hast du auch das Alte geprüft?“.
3. Gibt es schlechte Szenarien? Leere Eingabe, Fehler, komische Zahlen - nicht nur „wenn alles gut ist“.
4. Hängt sich der Test an den Sinn, nicht an den Stil? „Knopf Kaufen“, nicht eine namenlose css-Klasse.
5. Sind die Tests unabhängig? Jeder bereitet seine Daten selbst vor und verlässt sich nicht auf den Nachbarn.

Häufige Anfänger-Fehler bei TDD

• Code ohne Tests verlangen. „Mach einfach“ - und sich dann über Pannen wundern. Häng „arbeite nach TDD“ dran.
• Dem Grün glauben, ohne Rot gesehen zu haben. Der Test ist nie gefallen? Dann prüft er vielleicht gar nichts.
• Nur das neue Feature testen. Der Hauptnutzen von Tests ist zu fangen, dass Neues das Alte zerlegt hat.
• Nur „wenn alles gut ist“ prüfen. Echte Daten sind mal leer, mal krumm, mal bösartig.
• Sich an Zerbrechliches hängen. Ein Test auf css-Klasse fällt bei jeder Design-Änderung. Häng dich an den Sinn.
• Tests rausschmeißen, wenn sie stören. Ein fallender Test ist kein Feind. Das ist der Roboter, der dir gerade den Fuß gerettet hat.