A sua suíte end to end leva quatro horas e os desenvolvedores pararam de esperar por ela. Como você conserta isso?

Ataque em quatro frentes: paralelize entre workers, mova cobertura pirâmide abaixo para que testes de API e unitários substituam jornadas lentas de UI, corte testes duplicados e de baixo valor, e acelere o setup criando estado pela API em vez da UI. Depois divida a suíte para que um subconjunto rápido guarde os merges e a execução completa aconteça de madrugada.

Primeiro eu pego os dados, porque chutar quais testes são lentos normalmente dá errado. Eu puxo a duração por teste e quase sempre encontro um pequeno número de testes comendo uma fatia desproporcional, muitas vezes por causa de sleeps fixos ou por dirigir a UI num setup longo. Paralelização é a vitória estrutural mais rápida, mas ela só funciona se os testes estiverem devidamente isolados, então normalmente isso significa arrumar os dados de teste compartilhados primeiro. A alavanca maior é o rebalanceamento. Eu olho cada teste end to end e pergunto o que ele está realmente provando. Um teste que percorre seis telas para checar uma mensagem de validação é um teste unitário fantasiado, e o lugar dele é numa camada em que ele roda em milissegundos. Depois eu deleto, o que as pessoas acham desconfortável. Testes que nunca falharam por um motivo real, testes duplicando cobertura que existe em outro lugar, testes de funcionalidades que ninguém usa. Cobertura que custa mais do que devolve é um passivo. E eu faço setup pela API, então um teste de checkout cria a conta e o carrinho em duas chamadas em vez de quinze carregamentos de página. Por fim eu divido: quinze minutos de caminho crítico a cada merge, suíte completa de madrugada.