Idea

Unos tests escritos a posteriori por el autor del código validan su implementación, no la intención de negocio

Info

Escrito originalmente en francés. Traducido por IA — se ha preservado el sentido, no la prosa.

Idea principal

Un asistente al que se le piden tests una vez escrita la funcionalidad produce tests que pasan. Es lo esperable: los deriva de lo que acaba de escribir. Verifican que la función llamada con tal argumento devuelve lo que ya devuelve, que el componente muestra lo que ya muestra. Si la implementación entendió mal la necesidad, los tests ratifican ese malentendido y lo protegen frente a cualquier corrección futura.

El efecto visible es el inverso del efecto real. El repositorio muestra centenares de tests en verde, la suite se ejecuta en cada modificación y el producto parece asegurado — cuando nada en ese dispositivo ha confrontado nunca el código con el comportamiento que espera el negocio.

Eso es lo que distingue una cobertura de una estrategia de test: la primera mide cuánto código se recorre, la segunda decide qué comportamientos deben seguir siendo ciertos, a qué nivel verificarlos y qué riesgos deben quedar cubiertos.

Por qué es importante

Esto impide leer la presencia de tests como una prueba. Sobre un código generado, el número de tests es la cifra más fácil de obtener y la menos informativa: hay que saber de dónde vienen — de una intención formulada antes, o de una implementación releída después.

También explica por qué el tema es difícil para un perfil de producto. No tiene necesariamente práctica de desarrollo dirigido por tests, no siempre distingue test unitario, test de integración y test de extremo a extremo, y nunca ha tenido que formular una regla de negocio en forma de verificación — así que no tiene ninguna manera de darse cuenta de que lo que le devuelven es un espejo.

Matices y límites

Un test escrito después del código no carece de valor: protege de las regresiones, y eso ya es mucho sobre un código que no se relee. Lo que no hace es establecer que el comportamiento era el correcto.

Y invertir el orden tampoco basta: un test escrito antes, pero por quien entendió mal la necesidad, falla exactamente de la misma manera.

Preguntas abiertas

  • ¿Cómo puede alguien que nunca ha practicado el test expresar una intención de negocio de forma verificable, sin aprender antes el vocabulario del test?