chimera-test-the-wiring-not-the-class

Sie haben eine Komponente gebaut, die die Produktion indirekt erreicht: über eine Factory, eine Registry, einen Plugin-Loader, ein Config-Flag, einen Router, einen CLI-Einstiegspunkt, einen Dependency-Injection-Container. Ihre Tests konstruieren sie direkt und rufen ihre Methoden auf.

Jeder dieser Tests kann bestehen, während die Komponente im laufenden System unerreichbar ist — weil keiner von ihnen die Registrierung, den Standardwert des Flags oder den Zweig im Assembler ausübt, der entscheidet, ob sie überhaupt eingebunden wird.

Das gilt nicht für eine reine Funktion, die Aufrufer importieren und direkt aufrufen. Dort ist der Import die Verkabelung, und ein Unit-Test deckt sie ab. Es gilt auch nicht, wenn Sie einen Algorithmus bewusst isoliert testen — diese Tests sind richtig und sollten bleiben; diese Karte sagt nur, dass sie für sich allein nicht ausreichen.

1. Benennen Sie den Einstiegspunkt, den ein Nutzer tatsächlich trifft: das CLI-Subkommando, die HTTP-Route, die Run-Schleife des Agenten, den geplanten Job. Schreiben Sie ihn auf, bevor Sie den Test schreiben.

2. Schreiben Sie mindestens einen Test, der dort beginnt und keine Konstruktorargumente für Ihre Komponente übergibt. Wenn der Test Ihre Klasse benennen muss, damit das Feature passiert, testet er nicht die Verkabelung.

3. Bauen Sie das Objekt so, wie die Produktion es baut — rufen Sie die echte Factory oder den Config-Loader auf:

   # WRONG — proves the class, not the wiring: the component is handed to the thing under test,
   # so the test passes whether or not anything in production ever hands it over.
   assert "reminder" in render(feature=Feature(text="reminder"))
   
   # RIGHT — build it the way the entry point builds it, then look for the same observable
   assert "reminder" in build_the_real_way(config).render()
   

   Chimeras eigener Fall ist erwähnenswert, weil die Klasse nie kaputt war. Skill Cards hatten einen funktionierenden Retriever, einen funktionierenden Store und einen funktionierenden Injector — und chimera/config.py:244 liest skill_cards: bool = Field(default=False, ...), sodass auf einem Standard-Deployment nie etwas injiziert wurde. Jeder Unit-Test bestand. Die Messung, die es schließlich auffing, zählte geprägte Skills gegen injizierte Skills und fand 39 gegen null.

4. Prüfen Sie auf ein Beobachtbares, das nur erscheinen kann, wenn die Komponente erreicht wurde: Text im gerenderten Prompt, eine geschriebene Zeile, eine Log-Zeile, ein Exit-Code.

5. Prüfen Sie den Standardwert. Wenn das Feature hinter einem Flag ausgeliefert wird, fügen Sie einen eigenen Test hinzu, der den Standardwert ohne Overrides liest und behauptet, welcher er ist. Eine Suite, die immer nur mit erzwungenem Flag läuft, kann Ihnen nicht sagen, was Nutzer bekommen.

Einstiegspunkt-Tests sind langsamer, schwerer zu debuggen und lokalisieren schlechter: Wenn einer scheitert, wissen Sie, dass das Feature kaputt ist, aber nicht, welche von zehn Komponenten es kaputt gemacht hat. Das sind echte Kosten, und die falsche Reaktion auf diese Karte ist, die Unit-Tests zugunsten von End-to-End-Tests zu löschen. Behalten Sie beide — der Verkabelungstest sagt Ihnen, dass es kaputtging, der Unit-Test sagt Ihnen, was.

Durch den echten Einstiegspunkt zu gehen kann außerdem Dinge berühren, die Sie in der CI nicht berührt haben wollen: eine kostenpflichtige API, eine Live-Datenbank, ein Dateisystem außerhalb der Sandbox. Wenn der einzige Weg zum Einstiegspunkt darin besteht, Geld auszugeben oder Produktion zu verändern, erzwingen Sie es nicht; decken Sie stattdessen die Assembler-Funktion direkt ab und akzeptieren Sie, dass Sie einen Schritt vom wahren Pfad entfernt sind.

Und diese Karte fängt Erreichbarkeit, nicht Korrektheit. Ein Feature kann perfekt an den Einstiegspunkt verkabelt sein und trotzdem die falsche Antwort produzieren — ein grüner Verkabelungstest ist also kein Freibrief, darauf zu verzichten zu prüfen, was die Ausgabe tatsächlich sagt.