Inicio / Verificar lo que devuelve

Un verde no prueba nada hasta que no ha sido probado el mismo

Un control que nunca ha sido puesto en jaque por un caso que debe encontrar realmente no ha probado nada, en el sentido estricto de que probar exige que un comando concreto se haya ejecutado y que su salida haya sido leída: un detector roto da cero problemas, y eso se lee exactamente como un éxito.

Un script de verificación que informa cero problemas puede significar dos cosas opuestas: el sistema controlado está realmente limpio, o el control mismo ha dejado de funcionar. Nada en un resultado verde permite decidir entre las dos posibilidades mientras ese control no haya fallado al menos una vez frente a un caso que debe encontrar obligatoriamente.

La trampa del cero

Dos casos medidos hacen esta trampa concreta. Un patrón de escape roto produjo un día cero violaciones señaladas allí donde deberían haber aparecido miles. Otro patrón roto, a la inversa, señaló violaciones que no existían, y un orden de operaciones invertido produjo falsas alertas de manera continua en un caso real: la figura que acompaña esta lección cuantifica estos dos fallos con precisión. Ambos venían de la misma causa profunda, una verificación que nunca había sido probada sobre sí misma. El código de salida de una tarea programada plantea la misma trampa: un script puede anunciar un éxito durante semanas mientras el trabajo que se supone debe realizar falla silenciosamente por una razón externa a su propia gestión de errores.

El testigo positivo, demostrado por la ejecución

El remedio se resume en una regla. Un control debe buscar, en el mismo pase, al menos una cosa que debe encontrar, un caso conocido como malo: es el testigo positivo. La demostración se hace en pocas líneas. Un script que busca la palabra prohibida secreto en un archivo, con una expresión regular que olvidó la insensibilidad a mayúsculas, se ejecuta sobre un archivo que contiene dos veces esa palabra escrita con mayúscula inicial.

node verif.js fixture.txt
violations trouvees : 0

Cero. El archivo controlado contiene sin embargo dos ocurrencias de la palabra prohibida. Nada en este resultado distingue un archivo realmente limpio de un control roto, mientras nadie haya verificado que ese control sabe detectar un caso conocido. Añadir la insensibilidad a mayúsculas, exactamente el testigo que este control debe ahora encontrar, cambia el veredicto.

node verif2.js fixture.txt
violations trouvees : 2

Producir el testigo antes de declarar el control activo

El orden de las operaciones importa más de lo que parece. Cablea primero la escritura del testigo en caso de éxito, ejecuta la tarea una vez de verdad para que ese testigo exista realmente, y solo después declara la verificación activa. Invertir este orden, declarar una verificación de testigo antes de que nada escriba ese testigo, entrena a la gente a ignorar todo el sistema de vigilancia: un sistema ignorado vale menos que ningún sistema.

Un último hábito cierra el bucle. Renombra el testigo, nunca lo borres, y confirma que el control reacciona cada vez, luego restáuralo. Enumera también las condiciones que un control de completitud cubre en lugar de resumirlas detrás de una frase del tipo todo va bien: esa frase puede seguir siendo verdadera en una condición y falsa en las otras dos sin que nadie se dé cuenta.

Este principio se prolonga en prueba el verificador antes de creer su veredicto, que aplica la misma exigencia a un script que mide una cifra en lugar de una simple presencia.