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

Hai costruito un componente che la produzione raggiunge in modo indiretto: attraverso una factory, un registry, un plugin loader, un flag di configurazione, un router, un entrypoint della CLI, un container di dependency injection. I tuoi test lo costruiscono direttamente e ne chiamano i metodi.

Ognuno di quei test può passare mentre il componente è irraggiungibile nel sistema in esecuzione — perché nessuno di essi esercita la registrazione, il valore di default del flag, o il ramo dell'assemblatore che decide se includerlo del tutto.

Non si applica a una funzione pura che i chiamanti importano e invocano direttamente. Lì l'import è il cablaggio, e un unit test lo copre. Non si applica nemmeno quando stai deliberatamente testando un algoritmo in isolamento — quei test sono corretti e devono restare; questa card dice che da soli non bastano.

1. Nomina l'entrypoint che un utente colpisce davvero: il sottocomando della CLI, la route HTTP, il ciclo di esecuzione dell'agente, il job schedulato. Scrivilo prima di scrivere il test.

2. Scrivi almeno un test che parta da lì e non passi alcun argomento di costruzione per il tuo componente. Se il test deve nominare la tua classe perché la funzionalità accada, non sta testando il cablaggio.

3. Costruisci l'oggetto nel modo in cui lo costruisce la produzione — chiama la factory reale o il caricatore di configurazione:

   # 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()
   

   Il caso di Chimera merita di essere citato perché la classe non è mai stata rotta. Le skill card avevano un retriever funzionante, uno store funzionante e un injector funzionante — e chimera/config.py:244 recita skill_cards: bool = Field(default=False, ...), quindi su un deployment standard non veniva mai iniettato nulla. Ogni unit test passava. La misurazione che alla fine l'ha scoperto contava le skill coniate contro le skill iniettate e ha trovato 39 contro zero.

4. Verifica un osservabile che può comparire solo se il componente è stato raggiunto: del testo nel prompt renderizzato, una riga scritta, una riga di log, un exit code.

5. Verifica il default. Se la funzionalità viene rilasciata dietro un flag, aggiungi un test separato che legga il valore di default senza alcun override e ne verifichi il valore. Una suite che gira sempre e solo con il flag forzato a on non può dirti cosa ricevono gli utenti.

I test sull'entrypoint sono più lenti, più difficili da debuggare, e localizzano peggio: quando uno fallisce sai che la funzionalità è rotta ma non quale dei dieci componenti l'ha rotta. È un costo reale, e la risposta sbagliata a questa card è cancellare i tuoi unit test in favore di quelli end-to-end. Tienili entrambi — il test sul cablaggio ti dice che si è rotto, l'unit test ti dice cosa.

Passare per l'entrypoint reale può anche toccare cose che non vuoi toccare in CI: un'API a pagamento, un database vivo, un filesystem fuori dalla sandbox. Se l'unico modo per raggiungere l'entrypoint è spendere soldi o mutare la produzione, non forzarlo; copri invece direttamente la funzione di assemblaggio e accetta di essere a un passo dal percorso vero.

E questa card cattura la raggiungibilità, non la correttezza. Una funzionalità può essere cablata perfettamente all'entrypoint e produrre comunque la risposta sbagliata, quindi un test di cablaggio verde non è una licenza per saltare la verifica di cosa dica davvero l'output.