chimera-prove-the-test-discriminates
Una prueba de regresión que nunca has visto fallar es una suposición. Vuelve a romper el código y obsérvala ponerse en rojo antes de hacerle commit.
Conferida por quien revisó y leyó la tarjeta, no reclamada por el propio archivo. Una tarjeta que el agente destila durante una ejecución que consumió contenido no confiable nace contaminada y queda retenida para revisión antes de ser recuperada.
Cuándo viene a la mente
- escribiste una prueba de regresión
- arreglaste un bug y agregaste una prueba
- la prueba pasa, a entregar
- agregando una prueba después del arreglo
Evita y Comprueba es donde suele estar el valor. Haz es la sección que todo el mundo escribe.
El cuerpo de la tarjeta de arriba es una traducción. El original en inglés es lo que importa la CLI, lo que lee el agente en ejecución y lo que atestigua el hash de abajo.
Disparador
Arreglaste un bug y escribiste una prueba para que no pueda volver. La prueba pasa. Esa es toda la evidencia que tienes, y es la misma evidencia que tendrías si la prueba no verificara nada del bug en absoluto.
Aplica con más fuerza cuando la prueba se escribió después del arreglo, porque entonces el único código contra el que la prueba ha corrido es código donde el bug ya no está. Aplica menos a una prueba escrita primero, en rojo, en un ciclo TDD — a esa ya la viste fallar, que es justamente el sentido del ciclo.
No aplica a una prueba de comportamiento genuinamente nuevo, donde no hay un «antes» al que volver. Ahí, la comprobación discriminante es otra: borra la implementación nueva y confirma que la prueba falla por la ausencia, no por el bug.
Haz
- Identifica la edición exacta que constituye el arreglo — el hunk, no el commit. Si el arreglo es una comparación cambiada, esa comparación es lo que vas a deshacer.
- Deshazla. Haz
git stashdel arreglo, o invierte a mano esa única línea a su forma rota. - Ejecuta solo la prueba nueva:
pytest tests/test_thing.py::test_the_regression -x. - Lee el fallo. Debe ser tu aserción la que falla, con un mensaje sobre el comportamiento — no
un
SyntaxError, no un error de recolección, no unImportErrorde un archivo revertido a medias. Esos están en rojo por la razón equivocada y no prueban nada sobre la prueba. - Restaura el arreglo (
git stash pop) y confirma que la misma prueba ahora pasa. - Pon el hecho en el docstring de la prueba: qué se revirtió, y cómo se veía el fallo. La siguiente persona que toque esta prueba necesita saber que alguna vez se ejercitó contra el bug.
Evita
Verificar algo que es cierto en ambos mundos. La forma clásica:
result = parse_config(raw)
assert result is not None
assert "timeout" in result
El bug era que timeout volvía como la cadena "30" en vez del entero 30. Ambas aserciones se
cumplen de cualquier manera. Lo que discrimina es aquello que cambió:
# RIGHT — fails against the buggy code
assert parse_config(raw)["timeout"] == 30
assert isinstance(parse_config(raw)["timeout"], int)
Evita también revertir comentando una función entera o borrando un import para «hacer que falle rápido». Eso produce una ejecución en rojo que habría ocurrido para cualquier prueba del archivo, así que no te dice nada sobre esta. La reversión tiene que ser el arreglo y solo el arreglo.
Y evita el casi-acierto en el que la prueba llega al código arreglado por un camino que producción
nunca usa — ese es un fallo distinto, y su tarjeta es chimera-test-the-wiring-not-the-class.
Comprueba
Una pregunta binaria: ¿viste personalmente que esta prueba imprimiera un fallo causado por su propia aserción, contra el código sin arreglar?
Si sí, has terminado. Si la respuesta es «habría fallado», no has comprobado nada — esa frase es una predicción producida por el mismo razonamiento que escribió la prueba.
Mecánicamente:
git stash # remove the fix
pytest tests/test_x.py::test_regression # MUST be red, on your assertion
git stash pop # restore
pytest tests/test_x.py::test_regression # MUST be green
Rojo y luego verde, ambos observados, o la prueba está sin probar.
Riesgo
Algunos arreglos no se pueden revertir de forma barata: una actualización de dependencia, una migración de esquema, un archivo borrado, un cambio en una biblioteca empaquetada. Forzar una reversión ahí puede costar más de lo que vale la prueba. El repliegue honesto es reconstruir la entrada que solía romperlo y verificar el valor concreto, y luego decir con claridad en el docstring que la ejecución en rojo no se observó — una prueba sin probar que admite estar sin probar es muchísimo mejor que una que da a entender que se comprobó.
El peligro real de esta tarjeta es la reversión que olvidas deshacer. Hacer este baile en un árbol
de trabajo sucio es la manera de que una línea vuelta a romper se comitee junto a su propia prueba
de regresión, con la suite en verde porque restauraste el arreglo en el archivo equivocado. Ejecuta
git diff antes de hacer commit, siempre.
Y una prueba discriminante sigue siendo tan buena como el bug que entendiste. Prueba que la prueba detecta esta reversión. No prueba que arreglaste la causa raíz en lugar del síntoma, y tratar una corrida rojo-luego-verde como prueba de eso es una afirmación mayor de lo que la evidencia sostiene.
Cómo usarla
La tarjeta es un dato. Clona el repositorio e impórtala por ruta: lo que llega por la red se trata como contaminado y queda retenido a la espera de aprobación, que es el comportamiento deseable y la razón por la que aquí no hay un instalador de una línea.
git clone https://github.com/brcampidelli/chimera-agent.gitchimera skills-import chimera-agent/skills/chimera-prove-the-test-discriminates/SKILL.mdIntegridad
SHA-256 del archivo tal como se publicó. Quien lo importe puede comprobar que lo que recibió es lo que mostró esta página.
90d4bf00eb67055008527ee372153b2637fa2feea601ed6760997eda239f0b76