Pruebas que se comen sus propios datos: la causa más frecuente de flakiness
Los test que pasan una vez y fallan después suelen haber alterado el entorno o consumido datos irreversibles, no ser simplemente intermitentes.
A continuación se resume la publicación de Oleksandr R. sobre un fenómeno recurrente en test suites: un test que se ejecuta una vez con éxito y luego falla de manera consistente no es flakiness, sino que ha alterado su entorno.
La diferencia entre flakiness y consumo de datos
Flakiness implica que el resultado cambia sin patrón aparente, normalmente por race conditions o ventanas de tiempo. En cambio, cuando el primer run modifica el estado de manera que la precondición del test deja de cumplirse, la falla se vuelve predecible. El test no es “flaky” sino que “ate” su propio dato.
El autor identifica tres escenarios:
- Consumo irreversiblemente de datos – el test mueve un objeto a un estado sin control de reversión, por ejemplo usando un botón “add” sin “remove”. La segunda ejecución no encuentra nada que añadir.
- Estado dejado sin limpiar – el test cambia una configuración y no la revierte. La condición inicial “sin valor” ya no se cumple.
- Aging o expiración – un índice de búsqueda crea un registro, lo espera y lo valida, pero después de minutos el registro desaparece por expiración.
El diagnóstico se basa en repetir la ejecución. Si el segundo run falla porque no encuentra candidatos, el primer run consumió datos. Si la precondición falla, el primer run dejó estado.
Estrategias de mitigación
- Crear y limpiar – el test genera sus propios datos y los elimina en teardown. Es la única opción que escala.
- Tomar y restaurar – el test usa datos existentes y los vuelve al estado original a través de la misma API que lo modificó.
- Rotación – para estados que no se pueden revertir, el test busca un nuevo objetivo cada ejecución, evitando drenar un solo registro.
El autor enfatiza que un test no debe pasar el segundo run; un run extra antes del PR detecta la mayoría de estos errores.
Medición y métricas
Los sistemas de reporte de tests suelen agrupar por resultado (pass, fail, skip). Si un test se “come” sus datos, puede quedar marcado como skip, mejorando falsamente la tasa de éxito. Se recomienda registrar cada ejecución por test y usar patrones de tres resultados consecutivos para identificar regresiones o “starvation” (falta de datos).
Conclusión
Antes de etiquetar un fallo como “entorno sin datos”, verifique si el test mismo lo consumió. Esa verificación solo tarda unos segundos y evita tres investigaciones posteriores.
Enlaces útiles:
- Artículo original en Dev.to
