Escrito originalmente en francés. Traducido por IA — se ha preservado el sentido, no la prosa.
Idea principal
Quien ha escrito su código lo sostiene con la memoria: sabe qué decidió, dónde tomó un atajo, qué partes se tocan. Cuando el código lo produce un asistente a razón de decenas de commits al día, esa memoria no existe. Quedan pantallas que funcionan, un repositorio que no has leído entero y partes que no sabrías explicar en voz alta.
Lo que subsiste en esa situación son los tests. Un proyecto montado en unos días puede contar varios centenares; el asistente los relanza muy a menudo, y la mayor parte del tiempo no se rompe nada. Cuando algo se rompe, el test no dice solamente que hay un problema: dice qué comportamiento esperado ha dejado de respetarse, y por tanto localiza, allí donde la pantalla rota se limita a señalar.
El test no es aquí, por tanto, una garantía de calidad en el sentido habitual. Es el único instrumento que permite conservar un agarre sobre un sistema del que no tienes la memoria de construcción.
Por qué es importante
Esto cambia el argumento con el que se defienden los tests ante alguien que no programa. "Los tests son una buena práctica" no pesa nada frente a la velocidad; "sin ellos no tienes ninguna forma de saber qué acaba de romper la última modificación en un código que no has leído" se entiende de inmediato.
También señala qué hay que exigir prioritariamente a un asistente al que se confía la producción: no la cobertura por sí misma, sino la existencia de una red que haga interrogable el sistema a posteriori.
Matices y límites
El punto de apoyo no es un control. Los tests solo detectan lo que describen: no ven ni el derrumbe con volumetría real, ni los fallos de seguridad, ni una arquitectura que se vuelve impracticable de evolucionar.
Y la exigencia se dosifica. Una herramienta interna muy simple, de bajo riesgo y vida corta, no requiere una estrategia de test completa — la cuestión vuelve a ser la de la magnitud.
Preguntas abiertas
- Sobre un código que no has escrito, ¿cómo saber si el conjunto de tests cubre los comportamientos que importan, y no los que resultaban fáciles de escribir?