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

Você construiu um componente que a produção alcança indiretamente: por uma factory, um registry, um carregador de plugins, uma flag de config, um roteador, um entrypoint de CLI, um contêiner de injeção de dependências. Os seus testes o constroem diretamente e chamam os métodos dele.

Cada um desses testes pode passar enquanto o componente está inalcançável no sistema em execução — porque nada neles exercita o registro, o valor padrão da flag, ou o ramo do montador que decide se aquilo entra ou não.

Não se aplica a uma função pura que quem chama importa e chama diretamente. Ali, o import é a ligação, e um teste unitário a cobre. Também não se aplica quando você está deliberadamente testando um algoritmo isolado — esses testes estão corretos e devem continuar existindo; este card diz que eles não bastam sozinhos.

1. Nomeie o entrypoint que um usuário de fato usa: o subcomando de CLI, a rota HTTP, o loop de execução do agente, o job agendado. Escreva isso antes de escrever o teste.

2. Escreva pelo menos um teste que comece ali e não passe nenhum argumento de construtor para o seu componente. Se o teste precisa nomear a sua classe para a feature acontecer, ele não está testando a ligação.

3. Construa o objeto do jeito que a produção o constrói — chame a factory real ou o carregador de config:

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

   O caso do próprio Chimera vale ser nomeado porque a classe nunca esteve quebrada. Os skill cards tinham um retriever funcionando, um store funcionando e um injetor funcionando — e chimera/config.py:244 diz skill_cards: bool = Field(default=False, ...), então num deployment padrão nada nunca era injetado. Todo teste unitário passava. A medição que acabou pegando isso contou skills geradas contra skills injetadas e encontrou 39 contra zero.

4. Afirme sobre um observável que só pode aparecer se o componente foi alcançado: texto no prompt renderizado, uma linha escrita, uma linha de log, um código de saída.

5. Afirme o padrão. Se a feature vai atrás de uma flag, adicione um teste separado que lê o valor padrão sem nenhuma sobrescrita e afirma qual ele é. Uma suíte que só roda com a flag forçada ligada não consegue te dizer o que os usuários recebem.

Testes de entrypoint são mais lentos, mais difíceis de depurar, e localizam pior: quando um falha você sabe que a feature quebrou, mas não qual dos dez componentes a quebrou. Esse é um custo real, e a resposta errada a este card é apagar os seus testes unitários em favor de testes ponta a ponta. Mantenha os dois — o teste de ligação te diz que quebrou, o teste unitário te diz o quê.

Passar pelo entrypoint real também pode tocar coisas que você não quer tocadas no CI: uma API paga, um banco de dados ao vivo, um sistema de arquivos fora da sandbox. Se o único jeito de alcançar o entrypoint é gastar dinheiro ou mutar produção, não force; cubra a função montadora diretamente e aceite que você está a um passo do caminho verdadeiro.

E este card pega alcançabilidade, não correção. Uma feature pode estar perfeitamente ligada ao entrypoint e ainda produzir a resposta errada, então um teste de ligação verde não é licença para deixar de afirmar o que a saída de fato diz.