Anfang 2022 habe ich eine stille Entscheidung getroffen: Ich hörte auf, Unit Tests für die meisten WordPress- und Node-Projekte bei Seahawk zu schreiben. Nicht laut. Kein Blog-Post darüber. Ich hörte einfach auf. Die Begründung war schlüssig, dachte ich, wir schifften 15 bis 20 Client-Seiten pro Monat, ich hatte drei andere Entwickler im Rotationseinsatz, und die Tests, die ich schrieb, fühlten sich wie Dokumentation an, die niemand las. Manuelle QA fing die echten Bugs. Tests waren Theater.
Schnell vorlegen bis Ende 2023. GitHub Copilot war etwa acht Monate in meinem Editor. Ich hatte auch angefangen, Cursor nebenbei für alles Greenfield zu nutzen. Die Geschwindigkeit war wirklich bemerkenswert. Aber dann fing etwas an zu passieren. Bugs erschienen an Stellen, die ich nicht angefasst hatte. Logik, die korrekt aussah, war in Edge Cases falsch, die ich nie hätte prüfen können. Und das Schlimmste: Die AI wusste nicht, dass sie falsch war. Sie schrieb den kaputten Code mit der gleichen selbstsicheren Einrückung wie immer.
Da nahm ich die Tests wieder auf.
---
Der Zeitraum, in dem ich Tests abgebrochen habe (Und warum es damals sinnvoll war)
Ehrlich gesagt? Bei einer bestimmten Art von Projekt war es richtig, Tests zu überspringen. Wenn du eine fünf-seitige Broschüren-Website in WordPress baust, PHPUnit-Tests für ein Contact-Form-Plugin zu schreiben, ist Theater. Dazu stehe ich.
Seahawks Brot und Butter war lange Zeit genau diese Arbeit: großes Volumen, relativ niedrige Komplexität, klar definierter Scope. Ein Client gibt dir eine Figma-Datei, du baust sie, du machst QA, du shipmst sie. Die Feedback-Schleifen waren kurz. Wenn etwas kaputtging, wusstest du innerhalb von Stunden davon. Tests für diesen Kontext zu schreiben ist das Entwickler-Äquivalent, einen Post-it zu laminieren.
Aber ich verallgemeinerte diese Lektion viel zu aggressiv. Ich fing an, alle Projekte wie Broschüren-Websites zu behandeln. Auch die mit Custom-WooCommerce-Checkout-Flows. Auch das Fintech-Dashboard, das wir Anfang 2023 für einen Client in Frankfurt gebaut haben, völlig custom REST API, JWT Auth, drei verschiedene User-Permission-Tiers. Keine Tests. Nur „sorgfältige manuelle QA." Das war arrogant, und es hat uns getroffen.
Das Frankfurt-Projekt shipped mit einem Berechtigungs-Bug, der Editor-Level-Usern erlaubte, Admin-Level-Daten unter einer spezifischen Filterkombination abzufragen. Wir haben es erst bemerkt, als ihr internes Team sechs Wochen nach dem Launch eine Sicherheitsprüfung durchgeführt hat. Peinlich. Reparierbar. Aber genau die Art von Ding, das ein einfacher Integration-Test geflaggt hätte, bevor wir auch nur einen Pull Request gestellt hätten.
---
Was AI-Coding-Tools tatsächlich verändert haben
Hier ist das, was die meisten Leute übersehen, wenn sie über Copilot oder Cursor oder welches Modell gerade heiß ist sprechen: Der Code sieht richtig aus. Das ist das Problem.
Wenn ein Junior Developer fehlerhaften Code schreibt, sieht man die Unsicherheit oft darin. Seltsame Variablennamen, ein Kommentar, der sagt // bin mir unsicher, eine Funktion, die klar zweimal kopiert wurde. Der Code verrät seine eigene Fragilität. AI-Code tut das nicht. Er ist stilistisch konsistent, gut benannt und strukturiert auf eine Weise, die absichtlich wirkt. Das Selbstbewusstsein ist rein kosmetisch.
Studien der Stanford Human-Computer Interaction Group haben gezeigt, dass Entwickler, die AI-Assistants nutzen, dazu neigen, generierten Code beim ersten Lesen zu übervertrauen. Das entspricht meiner eigenen Erfahrung. Ich würde einen 40-Zeilen-Function von Copilot kurz anschauen, denken „ja, genau das hätte ich geschrieben", und weitermachen. Manchmal war es okay. Manchmal hatte er stillschweigend missverstanden, was ich eigentlich brauchte.
Der spezifische Fehlermodus, auf den ich immer wieder stieß: bedingte Logik rund um Edge Cases, die die AI keinen Grund hatte, zu antizipieren. Sie würde eine Funktion schreiben, die den Happy Path perfekt handhabt und dann stillschweigend bei Null-Eingaben, leeren Arrays oder nicht-standardisierten Datumsformaten fehlschlägt. Dinge, die mich dreißig Sekunden gekostet hätten zu durchdenken, wenn ich den Code selbst geschrieben hätte, weil ich daran gedacht hätte, während ich tippte.
Die Geschwindigkeitsfalle
Hier lauert eine echte Produktivitätsfalle. Die KI macht dich schnell. Schnelligkeit fühlt sich gut an. Du fängst an, schneller zu liefern, und du überprüfst weniger sorgfältig, weil die Geschwindigkeit wie ein Zeichen für Qualität wirkt. Das ist sie nicht. Geschwindigkeit und Korrektheit sind nicht korreliert, wenn du ein Sprachmodell aufforderst.
Im September habe ich ungefähr 40% mehr Features in ein Kundenprojekt gesteckt, als ich ohne KI-Unterstützung geschafft hätte. Das Projekt hatte aber auch mehr Bugs nach dem Launch als alles, das ich in zwei Jahren ausgeliefert habe. Keine katastrophalen Bugs. Aber nervige. Die Art, die das Vertrauen des Kunden zermürbt.
---
Warum Tests jetzt anders funktionieren (Mit KI im Spiel)
Als ich zum Testen zurückkam, kam ich nicht zum alten Workflow zurück. Tests zuerst schreiben, dann Implementation, dann KI-gestützte Code Review – das ist die Schleife, auf die ich mich jetzt geeinigt habe.
Das Interessante ist, dass KI eigentlich ausgezeichnet darin ist, Tests zu schreiben, auf eine Weise, wie sie nicht immer ausgezeichnet darin ist, Anwendungslogik zu schreiben. Gib Copilot eine gut definierte Funktionssignatur und fordere es auf, eine Test-Suite zu generieren, und es produziert eine Edge-Case-Abdeckung, die ich 20 Minuten lang manuell geschrieben hätte. Es stellt sich unglückliche Pfade gut vor, wenn die Aufgabe speziell „finde Wege, wie das schiefgehen kann" ist.
Ich habe das Ganze sozusagen invertiert. Ich schreibe die Test-Spezifikation. Die KI füllt die Test-Cases aus. Dann schreibt die KI die Implementierung. Dann lese ich die Implementierung durch die Linse dieser Tests, statt nur den Code kalt zu lesen.
Es ist langsamer als reines vibe-coding. Aber es ist schneller als der alte alles-manuell-schreiben-einschließlich-tests-Workflow. Und es hat seit Frankfurt null Permissions-Bugs ausgeliefert.
Die Tools, die ich tatsächlich nutze
- [Vitest](https://vitest.dev) für alles JavaScript oder TypeScript. Ersetzte letztes Jahr Jest komplett für mich, die Config ist vernünftiger und der Watch Mode ist schnell.
- PHPUnit weiterhin, für WordPress und benutzerdefinierte PHP-Arbeiten. Nichts hat es ersetzt.
- Cursors „test this function" Shortcut – wirklich eines der nützlichsten Single Features in jedem Editor, den ich je benutzt habe.
- GitHub Actions für CI. Tests laufen bei jedem Push zu main. Dauert bei den meisten Projekten etwa 90 Sekunden.
---
Das Argument gegen Tests (Steel-Manned)
Ich möchte dieser Position eine faire Chance geben, weil ich sie fast zwei Jahre lang vertreten habe.
Das echte Argument ist nicht „Tests sind nutzlos." Es ist „Tests haben einen Cost und viele Projekte rechtfertigen diesen Cost nicht." Eine Test Suite zu schreiben und zu warten kostet Zeit. Bei einem Projekt mit kurzer Lebensdauer, einer Campaign-Microsite, einer Marketing-Landing-Page, einem Hackathon-Prototype, hat diese Zeitinvestition keinen Return. Das Projekt wird tot sein, bevor die Tests dir irgendetwas sparen.
Und es gibt einen subtileren Punkt: schlechte Tests sind schlimmer als keine Tests. Eine Test-Suite, die besteht, weil die Tests tautologisch sind (du testest im Grunde nur, dass deine Funktion das zurückgibt, was du ihr gesagt hast), gibt dir falsches Vertrauen. Ich habe das in Agenturen gesehen. Entwickler, die Tests schreiben, die immer bestehen, weil niemand hinterfragt hat, was sie wirklich überprüfen.
Martin Fowler hat gut darüber geschrieben – Coverage-Prozentsätze sind kein Maß für Test-Qualität. Eine 90%-Coverage-Zahl kann eine völlig hohle Suite verdecken.
Also: nicht alles testen. Nicht testen, weil es sich professionell anfühlt. Testen, weil du eine Logik identifiziert hast, die tragend ist und teuer zu brechen wäre.
---
Was ich jetzt teste (und was nicht)
Hier ist die tatsächliche Entscheidung, zu der ich in den letzten acht oder neun Monaten gekommen bin:
Ich teste:
- Jede Funktion, die mit Geld, Berechtigungen oder Datentransformation umgeht
- Jeden API-Endpoint, der kein einfacher CRUD-Durchgang ist
- Custom Business Logic, bei der der Klient das exakte Verhalten schriftlich vorgegeben hat
- Alles, was eine KI geschrieben hat und das ich nicht Zeile für Zeile vollständig gelesen habe
Ich teste nicht:
- UI-Rendering (Snapshot-Tests haben mir in neun Jahren nicht ein einziges Mal geholfen. Nicht ein einziges Mal.)
- Wrapper für APIs von Drittanbietern, bei denen das externe Verhalten außerhalb meiner Kontrolle liegt
- One-off-Scripts, die einmal laufen und dann gelöscht werden
- Standard-WordPress-Hooks, es sei denn, sie machen etwas Ungewöhnliches
Das ist alles. Keine große Philosophie. Nur eine Liste basierend darauf, wo ich auf die Nase gefallen bin.
---
Der Workflow, der tatsächlich für mich funktioniert
Da ein paar Leute in Slack-Communities, in denen ich aktiv bin, danach gefragt haben, hier die tatsächliche Abfolge:
- Schreiben Sie einen kurzen Spec-Kommentar oben in der Datei, was dieses Modul tut, was es nicht tut, welche Edge Cases Sie bereits kennen.
- Bitte Cursor, Testfälle aus diesem Kommentar zu generieren, bevor ich irgendeine Implementierung schreibe.
- Überprüfe diese Testfälle. Lösche die dummen. Füge alle hinzu, die die KI übersehen hat.
- Lass Copilot oder Cursor die Implementierung schreiben.
- Führe die Tests aus. Sie werden fehlschlagen. Behebe die Implementierung (nicht die Tests).
- Lesen Sie den Diff vor dem Push, KI-gestützter Code braucht immer noch einen menschlichen Review-Pass.
Schritt 6 ist nicht verhandelbar. Ich habe in den letzten vier Monaten drei echte Bugs gefunden, nur indem ich das Diff langsam vor dem Push gelesen habe. Nichts Cleveres. Nur lesen.
Kent Becks ursprüngliche Idee von TDD war nie auf 100% Coverage oder die perfekte Methodik ausgerichtet. Es ging darum, eine Feedback-Schleife schnell genug aufzubauen, um Fehler zu erwischen, bevor sie sich häufen. Und genau diese Idee, schnelle Feedback-Schleifen, ist heute relevanter denn je. Noch relevanter als 2003. Der Grund? KI produziert Fehler schneller als jeder Developer, den ich je eingestellt habe.
---
FAQ
Verlangsamt das deine Delivery-Geschwindigkeit?
Bei komplexen Projekten rechnet man mit etwa 10 bis 15%. Bei einfachen Projekten kann das auch entfallen, denn die KI generiert die Tests so schnell, dass der Aufwand praktisch gegen null geht. Sobald ein Bug nach dem Launch teuer wird (und das trifft auf die meisten kommerziellen Projekte zu), lohnt sich dieser Overhead allemal.
Und TypeScript? Ersetzt starke Typisierung nicht eine Menge Tests?
Teilweise. TypeScript fängt eine ganze Klasse von Fehlern zur Compile-Zeit ab, für die du früher Tests brauchtest. Aber Typen testen nicht die Geschäftslogik. Sie überprüfen nicht, ob deine Rabattberechnungsfunktion die richtigen Regeln für Großkundenkunden anwendet. Das liegt immer noch bei dir.
Sollten Junior-Entwickler KI-Coding-Tools verwenden, wenn sie keine Tests schreiben?
Nein. Das ist eine starke Meinung. Ein Junior-Entwickler, der Copilot ohne Tests nutzt, fliegt im Grunde ein Flugzeug auf Autopilot, ohne zu verstehen, wie der Autopilot funktioniert oder wie man manuell landet. Die KI produziert Code, der aussieht wie Senior-Level, der Junior wird nicht wissen, welche Teile er anzweifeln sollte, und du wirst irgendwann einen Produktionsvorfall haben. Tests geben ihm wenigstens einen Mechanismus, um die Ausgabe zu überprüfen, die er akzeptiert.
Warum hast du überhaupt damit angefangen, nicht mehr zu testen?
Burnout, teilweise. Und dann diese Phase, wo jedes Projekt sich anfühlte wie ein Kinderspiel und Tests brachten einfach nichts. Der richtige Fehler war, nicht zu sehen, dass sich die Komplexität der Projekte verschoben hat. Und darauf nicht zu reagieren. Das ist die eigentliche Lektion — nicht „immer testen" oder „nie testen", sondern zu wissen, welche Kategorie ein Projekt wirklich braucht.
---
Tests schreiben fühlte sich früher nicht wie Schutz an. Wie Papierkram. Die KI hat das geändert. Nicht, weil sie schlecht wäre – sie macht mich deutlich schneller – sondern weil sie eine neue Sorte selbstbewusster, sauber formatierter, plausibel wirkender Fehler erzeugt hat. Fehler, die ich nicht erwische, wenn ich den Code wie früher durchlese. Tests sind dann nicht für die KI da. Sie sind für mich. Eine Art Zwang, erst zu überlegen, was ich vom Code wirklich brauche, bevor ich akzeptiere, was mir das Modell liefert.
Ich wünschte, ich hätte es vor zwei Jahren so gerahmt.
Weiterführende Lektüre: How I Use Claude Code Daily as a Founder Who Still Ships, tools, und SEO.