¿Cómo mantienes una suite de regresión?

Respuesta directa

Qué debe cubrir una buena respuesta

Cómo funciona

Una suite de regresión se gana su tiempo de ejecución atrapando roturas reales en comportamiento que importa ahora. Mantenerla significa podar: las pruebas de funcionalidades retiradas, los duplicados que afirman lo mismo por caminos distintos y las pruebas que nunca fallan se eliminan o fusionan. Cada prueba tiene dueño, para que un fallo tenga quien lo mire. Los fallos se clasifican como defecto del producto, de la prueba o de infraestructura, y se siguen las tasas; las pruebas inestables se ponen en cuarentena con plazo para arreglar o borrar. El tiempo se mide y se divide en un subconjunto rápido para pull requests y una ejecución completa nocturna. Tras cada incidente y funcionalidad, la suite se revisa para añadir lo que habría atrapado el problema en la capa más barata.

Ejemplo

Una revisión trimestral de una suite de 2.400 pruebas encontró 300 pruebas de un formato de exportación obsoleto, 180 casi duplicados de casos de validación de API y 40 pruebas que no habían fallado en dos años y no afirmaban nada significativo; eliminarlas recortó 20 minutos. Doce pruebas de interfaz inestables se pusieron en cuarentena y se reescribieron como pruebas de API. Tras un incidente en que escapó un bug de redondeo de moneda, se añadió una prueba unitaria de la función de redondeo en lugar de otra prueba de navegador.

Errores frecuentes

• Tratar el número de pruebas como métrica de calidad y no borrar nunca nada.
• Dejar pruebas inestables en la ejecución principal hasta que todos ignoran las builds rojas.
• Añadir una prueba end-to-end lenta por cada defecto escapado sin importar la capa.

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.