NCA Social Media
Aktualisiert:
Autor:
Roland Golla
Grüne Wasserwaage mit zentrierter Libelle und Schriftzug Lebende Spezifikation

Was bedeutet Tests als lebende Spezifikation?

Tests als lebende Spezifikation bedeutet, dass die automatisierten Tests eines Projekts beschreiben, was die Software tun soll, und diese Beschreibung bei jedem Lauf überprüft wird. Anders als ein Konzeptdokument kann eine lebende Spezifikation nicht veralten, ohne dass es jemand merkt. Wenn sich das Verhalten ändert, wird der Test rot.
Der englische Begriff dafür lautet Living Documentation. Er stammt aus der BDD Bewegung um Gojko Adzic und Cyrille Martraire und beschreibt Dokumentation, die im selben Takt wächst wie der Code, weil sie Teil des Codes ist. Ein Word Dokument beschreibt einen Wunsch. Ein grüner Test beschreibt einen Zustand.
2026 ist dieser Unterschied entscheidend geworden. Ein KI Coding Agent liest keine Konzepte, er liest das Repository. Was nicht als Test formuliert ist, existiert für ihn nicht. Tests sind damit nicht mehr nur ein Sicherheitsnetz, sondern der Auftrag selbst: die einzige Form von Spezifikation, die ein Agent nicht falsch interpretieren kann, weil sie ausführbar ist.
Inhalt

Lebende Spezifikation mit NCA: Schnelle Hilfe vom Experten

Testing ist bei Never Code Alone kein Nebenthema, sondern der Ausgangspunkt. Roland Golla arbeitet seit über 20 Jahren an Testabdeckung und Refactoring, ist Cypress Ambassador und hält seit 2018 Mob Programming Sessions, in denen Teams gemeinsam Tests schreiben. Unser Stack läuft mit PHPUnit, PHPStan, Rector PHP, Ruff und Pytest auf der Python Seite sowie Cypress mit Cypress Cloud für die Oberfläche. Auf der KI Seite arbeiten wir mit OpenCode und Open Weight Modellen.
Wer seine Tests zur Spezifikation ausbauen will, findet bei uns mehrere Anknüpfungspunkte: das Vibe Coding Consulting für die Gesamtstrategie, die Quality Gates für KI Code für die Durchsetzung in der Pipeline, das Example Mapping für den Weg von der Anforderung zum Testfall, das Schema Based AI Coding für maschinenprüfbare Verträge, das AI Coding Refactoring für gewachsene Codebasen und das NCA Ruhr Refactoring Consulting für PHP Projekte mit Altlasten.
Testabdeckung aufbauen mit Never Code Alone
Finde das passende Angebot für dein Projekt
Anfrage-Konfiguration
Starten Sie Ihre Anfrage
Projektart
Infos
Nachricht

Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.

CORE EXPERTISE

Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.

BFSG COMPLIANT

Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.

ENTERPRISE READY

Warum jede andere Dokumentation lügt

Jede Form von Dokumentation außerhalb des Codes hat dasselbe Problem: Sie kann falsch werden, ohne dass jemand etwas merkt. Das Confluence Dokument beschreibt einen Stand von vor zwei Jahren. Das Architekturbild zeigt einen Service, der längst abgeschaltet ist. Der Kommentar über der Methode beschreibt eine Logik, die im Refactoring verschwunden ist.
Ein Test hat diese Möglichkeit nicht. Er ist entweder grün oder rot. Wenn sich das Verhalten ändert und der Test nicht mitzieht, bricht der Build. Das ist der ganze Trick: Die Spezifikation wird bei jedem Commit gegen die Realität geprüft, und zwar automatisch, ohne dass jemand daran denken muss.
Genau deshalb ist ein Test mehr wert als seine Assertion. Er hält fest, welcher Fall vorgesehen war und was dabei herauskommen soll. Ein neuer Entwickler, der wissen will, wie eine Rabattlogik funktioniert, liest die Testklasse und nicht das Konzept. Ein KI Agent macht dasselbe, nur schneller.

Die vier Ebenen einer lebenden Spezifikation

Nicht jeder Test spezifiziert dasselbe. Eine Testsuite, die als Dokumentation taugen soll, braucht mehrere Ebenen, die unterschiedliche Fragen beantworten. Die Tabelle zeigt, welche Ebene wofür zuständig ist und womit wir sie im NCA Stack abdecken.
Ebene Beantwortet die Frage Werkzeuge im NCA Stack
Statische Analyse Passt der Code zu seinen eigenen Typen und Verträgen? PHPStan, Psalm, mypy, TypeScript
Unit Test Verhält sich diese Regel wie beschrieben? PHPUnit, Pytest, Vitest
Funktionaler Test Arbeiten die Bausteine im Zusammenspiel korrekt? PHPUnit mit Datenbank, Symfony Testclient
End to End Test Kann ein Mensch die Aufgabe tatsächlich erledigen? Cypress mit Cypress Cloud

Wie ein Test zur Spezifikation wird

Der Unterschied zwischen einem Test und einer Spezifikation liegt nicht in der Technik, sondern in der Benennung. Ein Test, der testCalculate heißt, prüft etwas. Ein Test, der beschreibt, welcher fachliche Fall gemeint ist, dokumentiert etwas. Derselbe Code, völlig anderer Wert für den nächsten Leser und für jeden Agenten.
Code: 
          
public function testCalculate(): void
{
    self::assertSame(0, $this->service->calc(5000, 0));
}

public function testVersandIstFreiAbFuenfzigEuroWarenwert(): void
{
    $versandkosten = $this->service->berechneVersand(
        warenwertInCent: 5000,
        gutscheinInCent: 0,
    );

    self::assertSame(0, $versandkosten);
}
Beide Tests prüfen dasselbe. Nur der zweite sagt jemandem, was die Regel ist. Wenn er rot wird, steht im Protokoll nicht ein kryptischer Methodenname, sondern der fachliche Satz, der gerade nicht mehr stimmt.
Drei Regeln reichen für den Anfang. Der Testname beschreibt die fachliche Regel in einem Satz. Benannte Parameter statt nackter Zahlen machen klar, was 5000 bedeutet. Und ein Test prüft genau eine Regel, nicht drei, damit ein roter Test eine eindeutige Aussage trifft.

Lebende Spezifikation als Grundlage für sicheres Refactoring

Refactoring heißt, die Struktur zu ändern, ohne das Verhalten zu ändern. Ohne lebende Spezifikation ist dieser Satz eine Behauptung. Niemand kann prüfen, ob das Verhalten wirklich gleich geblieben ist, weil niemand aufgeschrieben hat, welches Verhalten gemeint war.
Deshalb gilt bei NCA in gewachsenen Projekten immer dieselbe Reihenfolge. Zuerst Quality Gates aufbauen: statische Analyse, Unit Tests, funktionale Tests, E2E Tests mit Cypress. Erst danach wird aufgeräumt. Wer diese Reihenfolge dreht, refactored blind und merkt den Schaden im Livebetrieb.
Das gilt für Menschen und für Agenten gleichermaßen, für Agenten sogar schärfer. Ein Modell räumt gern mehr auf, als der Auftrag verlangt. Eine belastbare Testbasis ist die einzige Grenze, die es zuverlässig respektiert. Mehr dazu in unseren Beiträgen zu AI Coding Refactoring, AI Code Refactoring und AI Slop Refactoring.

Was das für KI Coding Agents bedeutet

Ein Agent braucht eine Abbruchbedingung. Ohne sie iteriert er, bis irgendetwas läuft, und genau das ist der Kern des Problems, das Teams 2026 in ihren Codebasen finden. Eine lebende Spezifikation liefert diese Bedingung: fertig ist, wenn die benannten Tests grün sind und keine bestehenden Tests rot geworden sind.
Wichtig ist die Reihenfolge. Wer den Agenten erst implementieren und danach Tests schreiben lässt, bekommt Tests, die zur Implementierung passen, nicht zur Anforderung. Das ist keine Spezifikation, sondern eine Bestätigung. Die Tests gehören vor die Implementierung, entweder von Hand oder vom Agenten unter enger Führung, aber immer gegen die fachliche Regel und nicht gegen den bereits geschriebenen Code.
Der zweite Punkt betrifft die Daten. Coding Modelle laufen bei uns nicht auf Kundenhardware, sondern in der Cloud. Deshalb gilt strikt: Coding aus der Cloud, Datenverarbeitung aus dem eigenen Netzwerk. Tests laufen gegen lokale Entwicklungsumgebungen mit Fake Daten, niemals gegen echte Personendaten. Wie das praktisch aussieht, beschreibt unser Beitrag zu Faker für realistische Testdaten. Wer souveräne Inferenz mit Zero Data Retention braucht, findet sie bei TensorX oder über unseren Netzwerkpartner Conversis in Duisburg.

Wo lebende Spezifikation an Grenzen stößt

Tests dokumentieren Verhalten, nicht Entscheidungen. Warum ein Team sich für PostgreSQL statt MySQL entschieden hat, welche Alternativen verworfen wurden und mit welcher Begründung, steht in keinem Test. Dafür braucht es andere Artefakte, etwa Architecture Decision Records.
Zweite Grenze: Eine Testsuite, die niemand pflegt, wird zur Last statt zur Hilfe. Flaky Tests, die sporadisch rot werden, zerstören das Vertrauen in die gesamte Spezifikation. Sobald ein Team anfängt, rote Builds zu ignorieren, ist die Dokumentation tot, auch wenn sie noch läuft.
Dritte Grenze: Vollständigkeit ist eine Illusion. Eine Testsuite beschreibt die Fälle, an die jemand gedacht hat. Deshalb ist der Weg von der Anforderung zum Testfall so wichtig und deshalb lohnt sich das Gespräch darüber, bevor der Code entsteht. Wie Regeln in der Datei landen, die der Agent tatsächlich liest, steht in unserem Beitrag zu rules.md und AGENTS.md.

Documentation has always been a source of frustration for everyone in software development.

Cyrille Martraire, Autor von Living Documentation, CTO und Mitgründer von Arolla – via InfoQ

Was Martraire damit meint

Die Frustration entsteht nicht daraus, dass Dokumentation fehlt, sondern daraus, dass sie nicht stimmt. Wer einmal einem veralteten Konzept gefolgt ist, glaubt dem nächsten nicht mehr. Martraires Antwort darauf lautet: Die Dokumentation gehört an die Sache selbst, an den Code, an die Tests, an die Pipeline. Dort kann sie nicht auseinanderlaufen, weil sie mitläuft. Für KI gestützte Entwicklung ist das kein Komfort mehr, sondern die Voraussetzung, dass ein Agent überhaupt weiß, woran er gemessen wird.

Aus der NCA Praxis: Der Testname ist die Dokumentation

Wir starten in Projekten fast nie mit dem Code, sondern mit dem Testprotokoll. Wer eine fremde Codebasis verstehen will, liest die Namen der Tests. Sind sie technisch benannt, weiß man nach einer Stunde immer noch nicht, was die Software eigentlich leisten soll. Sind sie fachlich benannt, hat man in zehn Minuten ein Bild von der Domäne.
Der zweite wiederkehrende Befund betrifft die Abdeckung. Fast jedes Team hat Tests, fast keines hat sie dort, wo das Geld liegt. Getestet wird, was leicht zu testen ist. Ungetestet bleibt die Preislogik, die Berechtigung, der Abrechnungslauf. Genau die Stellen, an denen ein Agent den größten Schaden anrichten kann.
Weiterführend passen unsere Beiträge zur Code Qualität mit KI Agenten, zu technischen Schulden durch Vibe Coding, zu Skalierbarkeit und Wartbarkeit, zu Agentic Coding Patterns, zur Human Readiness, zur Enterprise Readiness und zum Python Refactoring.
Auf der Werkzeugseite lohnen sich OpenSpec für Spec Driven Development, SwarmForge mit TDD Rollen, PHPSpec für Behavior Driven Development und der Digitale Zwilling als Denkmodell für Staging und Monitoring. Für PHP Teams greifen die NCA PHP AI Coding Guidelines, den Gesamtüberblick liefern der Vibe Coding Hub, die Vibe Coding Best Practices und die Einordnung zu Exact Coding.
CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.
NCA Vibe Coding Consulting

Roland Golla ist Entwickler aus Leidenschaft – seit über 20 Jahren. Er hat hunderte Projekte begleitet, von Legacy-Refactoring bis KI-Integration. Bei Vibe Coding verbindet er das Beste aus beiden Welten: Die Geschwindigkeit von KI-generiertem Code mit der Qualität professioneller Softwareentwicklung. Kein Bullshit, keine Agentur-Floskeln – direkte Hilfe von jemandem, der selbst täglich im Code steckt.

E-Mail Kontakt

Häufige Fragen zu Tests als lebende Spezifikation

Die meisten Rückfragen drehen sich um Abgrenzung, Aufwand und den konkreten Umgang mit KI Agenten im bestehenden Projekt.
Was bedeutet lebende Spezifikation 2026 genau?

Eine lebende Spezifikation ist eine Sammlung ausführbarer Tests, die beschreibt, was die Software leisten soll, und diese Beschreibung bei jedem Lauf überprüft. Sie kann nicht stillschweigend veralten, weil eine Abweichung sofort einen roten Build erzeugt. Der englische Begriff dafür ist Living Documentation.

Warum ist das 2026 bei KI Entwicklung so wichtig?

Weil ein KI Coding Agent eine Abbruchbedingung braucht. Ohne sie iteriert er weiter, bis irgendetwas läuft. Mit einer lebenden Spezifikation ist die Bedingung eindeutig: Die benannten Tests sind grün und kein bestehender Test ist rot geworden. Das macht aus einem offenen Auftrag einen prüfbaren.

Ersetzt eine lebende Spezifikation 2026 die Dokumentation?

Nur teilweise. Tests dokumentieren Verhalten, nicht Entscheidungen. Warum ein Team eine bestimmte Datenbank oder Architektur gewählt hat, gehört weiterhin in Architecture Decision Records. Alles, was sich als konkreter Fall formulieren lässt, gehört dagegen in Tests, weil es dort nicht veralten kann.

Wie fange ich 2026 in einem Projekt ohne Tests an?

Nicht mit Vollständigkeit, sondern mit Risiko. Zuerst die Stellen absichern, an denen ein Fehler Geld oder Vertrauen kostet: Preise, Berechtigungen, Abrechnung. Dazu statische Analyse als schnelle erste Stufe. Erst wenn dieses Netz steht, wird refactored oder ein Agent auf die Codebasis gelassen.

Ist eine lebende Spezifikation 2026 dasselbe wie BDD?

Nicht ganz. BDD ist die Praxis, aus Gesprächen und Beispielen Tests abzuleiten. Die lebende Spezifikation ist das Ergebnis davon. Man kann sie auch ohne Gherkin und ohne Cucumber erreichen, mit gut benannten PHPUnit oder Pytest Tests. Entscheidend ist die fachliche Benennung, nicht das Framework.

Wie benenne ich Tests so, dass sie dokumentieren?

Der Name beschreibt die fachliche Regel in einem Satz, nicht die technische Methode. Statt testCalculate also testVersandIstFreiAbFuenfzigEuroWarenwert. Wenn dieser Test rot wird, steht im Protokoll direkt der Satz, der nicht mehr stimmt. Das spart beim Debuggen mehr Zeit, als das Umbenennen kostet.

Soll der KI Agent die Tests selbst schreiben?

Unter Führung ja, danach nein. Lässt man den Agenten zuerst implementieren und dann Tests schreiben, entstehen Tests, die zur Implementierung passen und nicht zur Anforderung. Das ist eine Bestätigung, keine Spezifikation. Die Tests gehören vor die Implementierung und gegen die fachliche Regel formuliert.

Wie gehe ich mit flaky Tests um?

Sofort und konsequent. Ein Test, der sporadisch rot wird, zerstört das Vertrauen in die gesamte Suite. Sobald ein Team anfängt, rote Builds wegzuklicken, ist die Spezifikation tot, auch wenn sie technisch noch läuft. Entweder wird der Test stabilisiert oder er fliegt raus, ein Dazwischen gibt es nicht.

Welche Rolle spielen E2E Tests dabei?

Sie beantworten die Frage, die kein Unit Test beantworten kann: Kann ein Mensch die Aufgabe tatsächlich erledigen. Wir setzen dafür Cypress mit Cypress Cloud ein. Gerade bei KI generiertem Code ist diese Ebene wichtig, weil einzelne Bausteine korrekt sein können, während der Ablauf als Ganzes nicht funktioniert.

Darf ich Tests gegen echte Kundendaten laufen lassen?

Nein. Bei uns gilt: Coding aus der Cloud, Datenverarbeitung aus dem eigenen Netzwerk. Coding Modelle laufen nicht auf Kundenhardware, deshalb arbeiten Agenten immer gegen lokale Entwicklungsumgebungen mit Fake Daten. Für souveräne Inferenz mit Zero Data Retention gibt es EU Anbieter, etwa TensorX oder Conversis in Duisburg.

Wie viel Testabdeckung ist genug?

Die Prozentzahl ist die falsche Frage. Eine Suite mit 90 Prozent Abdeckung, die die Preislogik auslässt, ist wertlos. Sinnvoller ist die Frage, ob jede fachliche Regel mindestens einen Test hat, der ihren Grenzfall trifft. Abdeckung misst Zeilen, Spezifikation misst Regeln.

Lohnt sich das auch für kleine Projekte?

Für Prototypen nicht. Wer in wenigen Stunden prüft, ob eine Idee trägt, braucht Tempo statt Spezifikation. Sobald das Projekt aber in Betrieb geht und mehr als eine Person daran arbeitet, kippt die Rechnung. Ab dem Moment kostet fehlende Spezifikation mehr, als sie je gespart hat.