Cómo leer un fallo antes de tocarlo

Un pipeline en rojo produce una reacción muy rápida: abrir el spec y aflojar la afirmación hasta que pase. A veces el selector cambió y el arreglo es justo. Muchas veces el test estaba contando la verdad y el arreglo la esconde. Antes de tocar una línea conviene leer el fallo como se lee un experimento que no dio lo que uno esperaba.

Empiezo por tres cajones, y solo uno.

El producto hizo otra cosa. El botón no está, la API respondió 500, el permiso dejó entrar a quien no debía, el texto promete un estado que la pantalla no muestra. Eso es un bug. El test que lo señala no se «cura». Se archiva el defecto con el build, los pasos y el resultado real. Si alguien cambia la expectativa para que coincida con el bug, el suite deja de vigilar justo el caso que importaba.

El entorno no dejó hacer la prueba. Una base caída, un secreto que no llegó al job, un servicio de terceros con cuota vencida, un browser que no se instaló en el runner. También es un bloqueo, y tampoco se resuelve editando la afirmación. Se marca el job, se dice qué dependencia faltó y se vuelve a correr cuando el entorno está entero. Un reintento ciego, sin mirar el log, solo gasta minutos.

La prueba está mal escrita. Un selector atado a una clase que el diseño cambia todas las semanas. Un sleep fijo. Un dato que otro test borra. Un título que afirma tres cosas y falla por la segunda sin decir cuál. Ahí sí se toca el spec. El arreglo tiene que seguir afirmando el comportamiento, no la implementación accidental. Rol, nombre accesible y texto suelen sobrevivir mejor que una cadena de CSS.

El flake es un cuarto caso que la gente mezcla con los anteriores. Pasó al segundo intento, o falló una de cada diez corridas, sin un cambio de producto en el medio. Un flake no es un éxito. Es una medición inestable. Reintentar para poner el pipeline en verde esconde la tasa. Anotarla —cuántas veces, en qué paso, con qué traza— es lo que después permite decidir si se aísla el test o se arregla la condición de carrera.

Hay una pregunta que ordena los cuatro cajones: si este test desapareciera, ¿qué dejaríamos de saber? Si la respuesta es «nada, porque igual lo miro a mano», el test está de más o está duplicado. Si la respuesta es «no me enteraría de que un usuario sin permiso llega a la bandeja», entonces un parche para que quede verde es una pérdida de información.

Cuando un agente propone el diff, le pido lo mismo que le pediría a una persona nueva en el equipo. Que diga cuál de los cajones eligió. Que no mezcle un bug de producto con un selector frágil. Que no borre un caso porque estorbaba. Y que la evidencia del arreglo sea una corrida nueva, no el diff en sí. Un archivo modificado no demuestra que el comportamiento volvió.

Esto es lento la primera semana y rápido la décima. El reflejo de «hacer pasar el rojo» se reemplaza por una frase que cabe en el reporte: producto, entorno o prueba. Con eso, el pipeline vuelve a ser una medición y no una alarma a la que nadie hace caso.