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

Construiste un componente al que producción llega indirectamente: a través de una factory, un registro, un cargador de plugins, un flag de configuración, un router, un entrypoint de CLI, un contenedor de inyección de dependencias. Tus pruebas lo construyen directamente y llaman a sus métodos.

Cada una de esas pruebas puede pasar mientras el componente es inalcanzable en el sistema en ejecución — porque nada en ellas ejercita el registro, el valor por defecto del flag, o la rama del ensamblador que decide si incluirlo siquiera.

No aplica a una función pura que quienes la llaman importan y llaman directamente. Ahí, el import es el cableado, y una prueba unitaria lo cubre. Tampoco aplica cuando estás probando deliberadamente un algoritmo de forma aislada — esas pruebas son correctas y deben quedarse; esta tarjeta dice que no bastan por sí solas.

1. Nombra el entrypoint que un usuario realmente toca: el subcomando de la CLI, la ruta HTTP, el bucle de ejecución del agente, el job programado. Anótalo antes de escribir la prueba.

2. Escribe al menos una prueba que empiece ahí y no pase ningún argumento de constructor para tu componente. Si la prueba tiene que nombrar tu clase para que la funcionalidad ocurra, no está probando el cableado.

3. Construye el objeto como lo construye producción — llama a la factory real o al cargador de configuración:

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

   El caso propio de Chimera merece nombrarse porque la clase nunca estuvo rota. Las skill cards tenían un recuperador que funcionaba, un almacén que funcionaba y un inyector que funcionaba — y chimera/config.py:244 dice skill_cards: bool = Field(default=False, ...), así que en un despliegue de serie nunca se inyectaba nada. Todas las pruebas unitarias pasaban. La medición que finalmente lo detectó contó skills acuñadas contra skills inyectadas y encontró 39 contra cero.

4. Verifica sobre un observable que solo puede aparecer si el componente fue alcanzado: texto en el prompt renderizado, una fila escrita, una línea de log, un código de salida.

5. Verifica el valor por defecto. Si la funcionalidad se lanza detrás de un flag, añade una prueba aparte que lea el valor por defecto sin ninguna anulación y verifique cuál es. Una suite que solo se ejecuta con el flag forzado a activado no puede decirte qué reciben los usuarios.

Las pruebas de entrypoint son más lentas, más difíciles de depurar, y localizan peor: cuando una falla sabes que la funcionalidad está rota pero no cuál de diez componentes la rompió. Ese es un costo real, y la respuesta equivocada a esta tarjeta es borrar tus pruebas unitarias a favor de las de extremo a extremo. Conserva ambas — la prueba de cableado te dice que se rompió, la unitaria te dice qué.

Pasar por el entrypoint real también puede tocar cosas que no quieres tocar en CI: una API de pago, una base de datos viva, un sistema de archivos fuera del sandbox. Si la única forma de alcanzar el entrypoint es gastar dinero o mutar producción, no lo fuerces; cubre en su lugar la función ensambladora directamente y acepta que estás a un paso del camino verdadero.

Y esta tarjeta detecta alcanzabilidad, no corrección. Una funcionalidad puede estar perfectamente cableada al entrypoint y aun así producir la respuesta equivocada, así que una prueba de cableado en verde no es licencia para saltarse verificar qué dice realmente la salida.