Testes de unidade antigos / antigos quebrados

Eu trabalho para uma grande empresa e sou responsável por um grande aplicativo java com milhares de testes junit. Desde que mudei para essa função, houve 200 a 300 testes quebrados (provavelmente quebrados por anos). Os testes são antigos e frágeis e são uma bagunça de dependências de espaguete que normalmente terminam com dados de sandbox ativos.

Meu objetivo é 100% de aprovação nos testes para que possamos interromper as falhas de teste de unidade, mas não posso fazê-lo até resolver os testes quebrados. Eu tenho muito pouco orçamento porque o orçamento de manutenção é principalmente para suporte, mas minha equipe identificou e corrigiu os testes de frutas pendentes (principalmente problemas de configuração / recursos locais) e estamos com 30 a 40 testes realmente feios.

Quais são algumas opiniões sobre as melhores práticas? Não acho que os testes sejam valiosos, mas também não sei o que estão testando ou por que não funcionam sem se aprofundar, o que leva tempo e dinheiro que provavelmente não temos.

Acho que devemos documentar os status dos testes quebrados com tudo o que sabemos, excluir ou ignorar completamente os testes quebrados e inserir um item de trabalho / bug de prioridade mais baixa para investigar e corrigi-los. Estaremos então a 100% e começaremos a obter valor real dos outros testes e, se tivermos um ganho inesperado de manutenção / refatoração, poderemos recuperá-los novamente.

Qual seria a melhor abordagem?

Edit: Eu acho que essa é uma pergunta diferente desta, porque eu tenho uma direção clara para os testes que deveríamos escrever daqui para frente, mas eu herdei os testes com falha herdados para resolver antes que o grande conjunto atual de testes se torne significativo.

O que eu faria é primeiro desativar os testes que falham e sempre falharam.

Faça com que um teste falhe importa.

Ao investigar, você poderá perguntar às pessoas que estão mais tempo com sua empresa sobre elas, pode haver muito conhecimento tribal sobre elas que você pode documentar / capturar. Talvez a partir dos seus registros VCS. "Ah, esse teste sempre falhou desde que atualizamos para o X" ou outras informações podem ser úteis.

Depois de saber qual foi a funcionalidade em teste, você pode determinar:

• Nos preocupamos com isso sendo testado
• Quão importante é isso para ser testado

E depois faça uma lista de prioridades.

Provavelmente nada nesta lista é importante o suficiente para ter mais tempo depois, uma vez que já é ignorado há anos. Então eu não iria gastar demasiado muito tempo / recursos documentar e analisar todos esses testes quebrados.

Eu faria o seguinte:

1. Tente determinar exatamente o que os testes com falha estão tentando validar.

2. Triagem - se alguns testes estiverem tentando testar coisas sem importância, como um antigo estado do mundo, exclua-as. Se você perceber que alguns deles estão tentando validar algo importante, tente determinar se esses testes estão fazendo isso corretamente. Se eles estiverem testando incorretamente, faça-os testar corretamente.

3. Corrija o que estiver errado com seu código de produção, agora que você tem bons testes.

Lembre-se de contabilidade, cada linha de código é um passivo, mas pode ser avaliada incorretamente como um ativo. A deletechave pode criar muito valor para sua empresa.

200-300 testes quebrados (provavelmente quebrados por anos).

Ai! Eu enfrentei uma situação semelhante uma vez, mas com sete testes falhando, onde a equipe começou a ignorar o fato de que eles falharam por meses devido à mentalidade "sempre crunch".

Meu objetivo é 100% de aprovação nos testes para que possamos interromper as falhas de teste de unidade, mas não posso fazê-lo até resolver os testes quebrados.

Eu estava obcecado por um objetivo semelhante, apesar de ser apenas um desenvolvedor júnior da equipe, porque estava percebendo um acúmulo onde mais testes estavam falhando ao longo dos meses. Eu queria que transformassemos os de "avisos" em erros de construção (talvez um tanto desagradável para o resto da equipe).

Acho que devemos documentar os status dos testes quebrados com tudo o que sabemos, excluir ou ignorar completamente os testes quebrados e inserir um item de trabalho / bug de prioridade mais baixa para investigar e corrigi-los. Estaremos então a 100% e começaremos a obter valor real dos outros testes e, se tivermos um ganho inesperado de manutenção / refatoração, poderemos recuperá-los novamente.

Esses são meus pensamentos também. Você pode desativar temporariamente todos esses testes defeituosos, visitá-los lentamente e corrigi-los com o tempo. É importante agendar essas correções se você as considerar realmente importantes, mesmo que sejam de baixa prioridade, pois é fácil para esses itens simplesmente não serem corrigidos. A prioridade para mim é garantir que não sejam introduzidos novos testes que falhem.

Como qualquer tipo de aviso, se não quebrar a construção, eles tendem a se acumular rapidamente. Isso pressupõe esse tipo de dinâmica de equipe em que o hábito de ignorar avisos (testes falhados neste caso) pode levar rapidamente a mais avisos a serem introduzidos e reduzir a tentação de manter esses avisos em zero.

Uma equipe muito consciente pode não sofrer esses problemas e evitar a introdução de novos avisos (novas falhas nos testes), mas é definitivamente mais seguro ficar um pouco mais pesado e exercitar uma estratégia de prevenção, transformando-os em erros que devem ser corrigidos antes de um teste. processo de mesclagem.

Portanto, minha sugestão é a mesma que a sua (embora apenas uma opinião forte - talvez possa apoiar isso com métricas e uma resposta mais científica). Desative esses testes antigos e coloque-o no cronograma para eventualmente corrigi-los. A primeira prioridade é garantir que esse problema não se acumule e comece a piorar, certificando-se de que os testes atualmente bem-sucedidos não sejam ignorados se começarem a falhar.

De certa forma, você tem sorte. É melhor ter testes que falham e não deveriam (eles avisam pelo menos que algo está errado) do que ter testes que passam e não deveriam (o que lhe dá uma falsa sensação de segurança).
Obviamente, se você possui o primeiro, é bem provável que o tenha também (portanto, os testes são aprovados, mas devem falhar).

Como já foi dito, por enquanto, desative os testes que falharam, mas solicite que eles imprimam uma mensagem no log de testes como um lembrete constante sobre eles.
Mas você definitivamente deve encontrar os recursos para repassar todo o seu conjunto de testes, a fim de descobrir e eliminar os testes que passam e não deveriam, porque cada um deles significa que há um bug no seu código que você não está detectando no momento. ciclos de teste.

Usando essa nuvem escura que paira sobre a base de código, é possível que você consiga algum orçamento para uma revisão completa de seus testes, se fizer o certo e não apenas dizer a eles que acha que alguns testes devem ser vistos porque parecem falham quando não deveriam, mas você não confia que seus testes estão detectando erros no seu código corretamente, que o conjunto de testes não pode ser confiável para fazer seu trabalho.
Quando fiz isso em uma empresa anterior, estava trabalhando para essa revisão e constatou que centenas de testes foram escritos com suposições incorretas sobre o que o código DEVE fazer, levando ao código (que foi escrito usando as mesmas suposições incorretas) passou nos testes quando realmente não deveria ter. Corrigir isso resolveu muitos problemas desagradáveis ​​que, embora a maioria não fossem críticos, poderiam ter derrubado alguns sistemas importantes.

Qualquer teste de unidade com falha deve fazer com que a construção seja interrompida. Bom em você por realizá-lo e estabelecer esse objetivo. A mente humana dificilmente pode ignorar algo mais completamente do que a fonte de um falso alarme persistente .

Jogue fora esses testes e não olhe para trás. Se eles estão falhando há anos e não foram abordados até agora, não são uma prioridade.

Quanto ao conhecimento tribal, se as pessoas com conhecimento tribal ainda estão por perto, deveriam ter corrigido os testes que falharam agora. Caso contrário, novamente, essas não são uma prioridade.

Se não houver conhecimento tribal, você e sua equipe terão que se apropriar da lógica. Os testes que falham podem ser mais enganosos do que úteis - o mundo pode ter mudado.

Crie novos testes relevantes e continue escrevendo um ótimo código.