¿Cómo diagnosticas una prueba inestable?

Respuesta directa

Qué debe cubrir una buena respuesta

Cómo funciona

Una prueba inestable es una prueba con un bug dentro o un bug debajo. El diagnóstico empieza haciéndola fallar a voluntad: ejecutarla cincuenta veces, en paralelo con sus vecinas y con trazas, capturas y logs guardados al fallar. La evidencia clasifica la causa: tiempo, cuando la prueba afirma antes de que la aplicación se asiente; estado compartido, cuando otra prueba o un registro sobrante cambia el resultado; entorno, como un runner lento o una dependencia de red; o una carrera real del producto que solo aparece bajo carga. El arreglo corresponde a la clase, esperando condiciones observables en lugar de dormir, aislando datos o abriendo un bug de producto, y la prueba se pone en cuarentena con dueño hasta arreglarla, nunca simplemente se reintenta.

Ejemplo

Una prueba de checkout fallaba el 3 por ciento de las veces; cincuenta ejecuciones con trazas mostraron que la afirmación se disparaba antes de que terminara una solicitud de recálculo de precio, y el total visible estaba momentáneamente obsoleto. El arreglo sustituyó una espera de 500 ms por una espera a que la solicitud de red terminara y el total coincidiera. Otra prueba que fallaba solo después de las 14:00 UTC resultó depender de un fixture con fecha fija, una clase de estado compartido.

Errores frecuentes

• Añadir reintentos para ocultar la inestabilidad en lugar de arreglarla.
• Corregir el tiempo con esperas más largas que ralentizan la suite y siguen siendo inestables.
• Suponer que la culpa es de la prueba y perder una condición de carrera real en el producto.

Una estructura útil para responder

Responde desde tu propia experiencia.

No memorices un guion: usa solo ejemplos que puedas explicar con honestidad en preguntas posteriores.