Os testes são valiosos. No mínimo, eles registram que alguém considerou que deveria gastar tempo escrevendo-os; portanto, presumivelmente, eles tiveram algum valor para alguém uma vez. Com sorte, eles conterão um registro completo de todos os recursos e bugs em que a equipe já trabalhou - embora também possam ter sido uma maneira de atingir um número arbitrário de cobertura de teste sem ser cuidadosamente pensado. Até você olhar para eles, você não saberá qual é o caso aqui.
Se a maioria dos seus testes passar na maior parte do tempo, apenas dê uma olhada e invista o tempo em descobrir o que os poucos testes que falharam estavam tentando fazer e corrigi-los ou melhorá-los para que o trabalho seja mais fácil na próxima vez. Nesse caso, pule para a seção Determinar a intenção de cada teste , para obter alguns conselhos sobre o que fazer com um pequeno número de testes com falha.
Por outro lado, você pode se deparar com uma compilação vermelha agora, e centenas ou até milhares de testes que não passaram por um tempo, e Jenkins não é verde há muito tempo. Nesse momento, o status de criação do Jenkins se tornou inútil e um indicador importante dos problemas com seu check-in não está mais funcionando. Você precisa corrigir isso, mas não pode parar todo o progresso enquanto arruma a bagunça na sua sala de estar.
Para manter sua sanidade mental enquanto executa a arqueologia necessária para determinar qual valor pode ser recuperado dos testes que falharam, recomendo as seguintes etapas:
Desative temporariamente os testes com falha.
Existem várias maneiras de fazer isso, dependendo do seu ambiente, que você não descreve claramente, por isso não posso recomendar nenhuma.
Algumas estruturas suportam a noção de falhas esperadas. Se o seu for o caso, isso é ótimo, pois você verá uma contagem regressiva de quantos testes restam nesta categoria e será informado se alguns deles começarem a passar inesperadamente.
Algumas estruturas oferecem suporte a grupos de testes e permitem que você informe ao Hudson apenas para executar alguns dos testes ou ignorar um grupo de testes. Isso significa que você pode ocasionalmente executar o grupo de teste manualmente para ver se algum deles está passando.
Algumas estruturas permitem que você anote ou marque testes únicos para serem ignorados. É mais difícil administrá-los como um grupo nesse caso, mas impede que eles o distraiam.
Você pode mover os testes para uma árvore de origem que normalmente não está incluída na compilação.
In extremis, você pode excluir o código do HEAD do sistema de controle de versão, mas isso tornará mais difícil reconhecer quando a terceira fase for concluída.
O objetivo é fazer com que Jenkins fique verde o mais rápido possível, para que você possa começar a se mover na direção certa o mais rápido possível.
Mantenha os testes relevantes.
Resolva para adicionar novos testes ao adicionar ou modificar o código e comprometa-se a manter todos os testes aprovados.
Os testes podem falhar por vários motivos, incluindo o fato de que não eram testes bem escritos para começar. Mas uma vez que você tenha Jenkins verde, mantê-lo assim é realmente importante.
Acostume-se a escrever bons testes e faça disso um grande negócio se os testes começarem a falhar.
Determine a intenção de cada teste.
Passe pelos testes desativados, um por um. Comece com os que afetam os módulos que você altera com mais frequência. Determine a intenção do teste e o motivo da falha.
Ele testa um recurso que foi removido da base de código de propósito? Então você provavelmente pode excluí-lo.
Está pegando um bug que ninguém notou ainda? Restabeleça o teste e corrija o erro.
Está falhando porque estava fazendo suposições injustificadas (por exemplo, assumindo que o texto do botão sempre estaria em inglês, mas agora você localizou seu aplicativo para vários idiomas)? Depois, descubra como fazer o teste se concentrar em uma única coisa e isolá-lo das alterações não relacionadas da melhor maneira possível.
O teste se estende por todo o aplicativo e representa um teste do sistema? Em seguida, remova-o do seu conjunto principal de testes Jenkins e adicione-o ao conjunto Regression que é executado com menos frequência.
A arquitetura do aplicativo mudou além do reconhecimento, para que o teste não faça mais nada útil? Delete isso.
O teste foi adicionado para aumentar artificialmente as estatísticas de cobertura do código, mas na verdade nada mais é do que confirmar que o código é compilado corretamente e não entra em um loop infinito? Ou então, o teste simplesmente confirma que a estrutura de simulação selecionada retorna os resultados que você acabou de informar? Delete isso.
Como resultado disso, alguns testes permanecerão, alguns serão modificados, outros serão divididos em vários pedaços independentes e pequenos, e alguns serão removidos. Enquanto você ainda estiver progredindo com novos requisitos, reservar um pouco de tempo para lidar com dívidas técnicas como essa é a responsabilidade.