Hay algo peor que un test que falla.

Un test que miente.

Y no hablo de un bug en el código de testeo. Hablo de esas situaciones donde la suite está toda en verde, el pipeline pasó, el reporte dice “100% OK” y vos sentís esa incomodidad en el estómago. Algo no cierra.

El test dice una cosa. La realidad, otra.

Te pasó. Me pasó. Y si no te pasó, es cuestión de tiempo.

El test que pasa pero no prueba

Arranquemos por el mentiroso más peligroso: el falso positivo.

El test está verde. Todo bien. Pero en producción el flujo está roto.

¿Cómo carajo puede pasar? Fácil: el test validó algo que no era lo importante, o validó con datos que no representan la realidad, o simplemente ejercitó código sin verificar el resultado real.

Un ejemplo que vi más veces de las que quisiera:

Cuando el usuario hace clic en "Guardar"
Entonces ve el mensaje "Operación exitosa"

El test pasa. El mensaje aparece. Pero en la base de datos no se guardó un sorete. O se guardó a medias. O se guardó con un estado inconsistente que va a explotar tres pantallas después.

El test no miente técnicamente — el mensaje sí apareció. Pero miente sobre lo que importa.

Un test que no verifica el resultado real es un test que miente.

El test que falla pero no debería

Del otro lado, el falso negativo. Este es el que te hace perder la tarde.

El test falla, vas corriendo a ver qué se rompió, revisás logs, debuggeás… y resulta que no falló nada. Era el entorno, un timeout que se quedó corto, datos que alguien modificó sin avisar, o una condición de carrera que aparece cada 47 ejecuciones.

El problema con este mentiroso es que te quema la confianza.

Cuando los tests fallan por razones ajenas al código, dejás de creerles. Y cuando dejás de creerles, empezás a ignorarlos. Y cuando empezás a ignorarlos, el día que fallan por algo real nadie se entera.

Es el equivalente a una alarma de auto que salta porque pasó un bondi. Al tercer día ni la escuchás.

Los tres tipos de mentira que más veo

1. El test que depende de datos frágiles

El caso clásico: el test asume que el usuario “test@email.com” tiene tres órdenes en estado pendiente. Un día alguien limpia la base, o corre otro test antes, o cambia el fixture, y el test empieza a comportarse raro. A veces pasa, a veces falla.

El test no está validando funcionalidad. Está validando que un dato específico exista en un momento específico. Eso no es un test. Es un deseo.

2. El test que no limpia lo que ensucia

Vos creás un recurso, ejecutás el flujo, validás… y no limpiás. Después el siguiente test encuentra ese recurso y se confunde. O peor: el mismo test corre dos veces y la segunda vez falla porque el recurso ya existe.

Eso no es un bug intermitente. Es un test mal diseñado.

3. El test que duerme con wait fijos

Thread.sleep(3000). cy.wait(2000). page.waitForTimeout(5000).

Cada vez que veo un sleep fijo en un test, sé que ese test miente. No está esperando una condición real. Está rezando. Y cuando la máquina de CI está más lenta, o la red tiene latencia, o el servicio tarda un segundo más, la oración no alcanza y el test falla.

O peor: no falla, pero validó antes de que el estado real se alcanzara. Eso es un falso positivo esperando a pasar.

Por qué nos mienten los tests

Acá es donde se pone interesante: los tests no mienten por maldad. Mienten porque nosotros los hacemos mentir.

  • Por acoplamiento: cuando el test depende de detalles de implementación en vez de comportamiento.
  • Por datos compartidos: cuando varios tests se pisan los datos porque comparten estado.
  • Por validaciones débiles: cuando verificás que algo “se ve” pero no que “funciona”.
  • Por desconocimiento del sistema: cuando automatizás sin entender qué estás probando realmente.
  • Por atajos: cuando preferís que el test pase antes que preguntarte si está probando algo útil.

Un test automatizado es un programa que valida otro programa. Si lo tratás como un trámite, el resultado va a ser un trámite.

Cómo detectar que un test te está mintiendo

Hay señales. No hace falta ser medium ni tener una bola de cristal.

La suite siempre está verde. Siempre. Hace semanas que no falla nada. ¿Es porque el producto es perfecto o porque los tests no están detectando nada? En mi experiencia, lo segundo es mucho más común.

El test pasa con datos ridículos. Si podés mandarle cualquier cosa y el test sigue en verde, no está validando. Está haciendo compañía.

Nadie entiende qué cubre el test. Cuando preguntás “¿este test qué valida?” y la respuesta es “lee el código”, hay un problema de diseño.

El test falla por cosas que no son bugs. Timeouts, condiciones de carrera, datos que no están, dependencias externas caídas. Si el motivo de falla más común no es un defecto real, el test no es confiable.

Modificás el código de negocio y el test ni se inmuta. Cambiaste la lógica de persistencia, tocaste una validación central, moviste un flujo… y el test sigue pasando como si nada. O el test no cubría eso, o está tan abstraído que perdió el rastro de lo que importa.

Qué hago yo para que los tests no mientan

No tengo la fórmula mágica. Pero tengo algunas cosas que me funcionan.

Diseñar el test antes de escribirlo. Parece una boludez, pero si no podés explicar en dos oraciones qué validás y por qué, probablemente no lo tengas claro.

Validar el resultado, no el camino. Que el test verifique que el dato se guardó, que el estado cambió, que la respuesta es la esperada. No que “se hizo clic en el botón” o “se navegó a tal página”. Eso es cómo se hizo, no qué se logró.

Datos autocontenidos. Cada test crea lo que necesita y limpia lo que ensucia. Si el test no puede correr aislado, no es un test. Es una dependencia con sintaxis de test.

Esperar por condiciones, no por tiempos. En vez de sleep(3000), esperar a que el elemento aparezca, a que la respuesta llegue, a que el estado cambie. La diferencia entre rezar y verificar.

Fallar rápido y fallar claro. Si el test falla, el mensaje de error debería decir exactamente qué esperaba y qué recibió. “Expected X, got Y” con contexto. No un stack trace ilegible ni un timeout genérico que te obliga a debuggear veinte minutos.

Revisar los tests cuando revisás el código. Un PR que modifica comportamiento de negocio y no toca ningún test merece una pregunta: ¿los tests cubren esto? Si la respuesta es “no”, estás sumando comportamiento sin red.

Cada tanto, romper algo a propósito. Agarrá un flujo, metele un cambio que sabés que debería fallar, y corré la suite. Si los tests no se enteran, tu suite te está mintiendo y necesitás ajustarla.

Suena extremo, pero es una de las pruebas más sanas que podés hacer.

Lo que me quedó claro

Un test automatizado no vale por existir. Vale por lo que detecta y por la confianza que genera.

Y la confianza no se compra con cantidad. Se construye con diseño.

Un test que miente no es inofensivo. Te hace sentir cubierto cuando no lo estás. Te hace mergear con tranquilidad cosas que deberían preocuparte. Te hace ignorar rojos que deberían frenar un deploy.

Es como un detector de humo que a veces suena con el vapor de la ducha y a veces no suena con un incendio. En un mes dejaste de mirarlo. Y el día que necesitás que funcione, ya es tarde.

La próxima vez que mires tu suite toda en verde, hacete la pregunta incómoda:

¿Estos tests me están diciendo la verdad, o me están diciendo lo que quiero escuchar?