¿Cómo compruebas que tu herramienta hace lo que debe, aun después de que el agente la cambie?

El oficio que ya tienes

Formular la hipótesis antes de mirar los datos. Ya sabes que un criterio fijado después de ver el resultado se acomoda a él. Una prueba escrita antes del cambio fija qué cuenta como éxito, y el agente no puede moverlo sin que lo notes.

En Marienthal

Una prueba manda al servidor de la encuesta de clase una respuesta sin la escala de cansancio y afirma que no entra a la base. Se escribe y se corre antes del cambio, y falla. Después el agente agrega la validación, la prueba pasa y se corren las demás para confirmar que una respuesta completa sigue entrando.

En tu proyecto

Escribes tres afirmaciones sobre lo que tu herramienta tiene que cumplir —una sobre lo que guarda, una sobre lo que rechaza y una sobre lo que muestra el tablero— y las conviertes en pruebas con el agente. Las ves fallar o pasar, y las corres antes de tu próxima publicación.

Conceptos

Prueba automática

Un pequeño programa que usa tu herramienta con datos conocidos y revisa que el resultado sea el esperado.

Falla esperada

Ver fallar la prueba antes del cambio. Confirma que la prueba de verdad detecta lo que dice detectar.

Regresión

Algo que ya funcionaba y deja de funcionar por un cambio en otra parte. Correr todas las pruebas la detecta.

Caso límite

Una entrada en el borde de lo válido: un campo vacío, un número fuera de rango, una respuesta a medias.

Instrumental

claude

Pedir el cambio que hace pasar la prueba, sin tocar la prueba, y que corra todas al terminar.

git diff

Confirmar que el agente cambió el código y no la prueba.

git commit

Guardar la prueba junto con el cambio que la hace pasar, con la razón en el mensaje.