Tu suite de extremo a extremo tarda cuatro horas y los desarrolladores han dejado de esperarla. ¿Cómo lo arreglas?

Atácalo por cuatro frentes: paraleliza entre workers, baja cobertura por la pirámide para que los tests de API y unitarios sustituyan a recorridos lentos de interfaz, elimina tests duplicados y de poco valor, y acelera la preparación creando el estado por la API en vez de por la interfaz. Después divide la suite para que un subconjunto rápido condicione los merges y la ejecución completa se haga de noche.

Primero consigo los datos, porque adivinar qué tests son lentos suele salir mal. Saco las duraciones por test y casi siempre encuentro un número pequeño de tests comiéndose una parte desproporcionada, muchas veces por sleeps fijos o por recorrer la interfaz en una preparación larga. La paralelización es la victoria estructural más rápida, pero solo funciona si los tests están bien aislados, así que eso normalmente significa arreglar antes los datos de prueba compartidos. La palanca más grande es reequilibrar. Miro cada test de extremo a extremo y me pregunto qué está demostrando en realidad. Un test que recorre seis pantallas para comprobar un mensaje de validación es un test unitario disfrazado, y su sitio es una capa donde corre en milisegundos. Después borro, cosa que a la gente le incomoda. Tests que nunca han fallado por un motivo real, tests que duplican cobertura que existe en otro sitio, tests de funcionalidades que no usa nadie. La cobertura que cuesta más de lo que devuelve es un lastre. Y hago la preparación por la API, para que un test de compra cree su cuenta y su carrito en dos llamadas y no en quince cargas de página. Por último la divido: quince minutos de ruta crítica en cada merge, suite completa de noche.