Quais são as vantagens tangíveis dos testes de unidade adequados sobre o teste funcional, chamados testes de unidade

Um projeto no qual estou trabalhando tem vários testes herdados que não foram devidamente ridicularizados. Por causa disso, a única dependência que possui é o EasyMock, que não oferece suporte a estática, construtores com argumentos, etc. A adição de powermock para lidar com esses casos está sendo reduzida como custo proibitivo devido à necessidade de atualizar o projeto existente para apoiá-lo (Outra discussão).

Minhas perguntas são: quais são os benefícios tangíveis do mundo REAL dos testes de unidade adequados que posso usar para recuar? Há alguns? Estou apenas sendo um defensor dizendo que testes de unidade ruins (mesmo que funcionem) são ruins? A cobertura do código é tão eficaz?

• Recursos

  Você precisa de um banco de dados de teste para executar os testes. O hardware para executar o banco de dados é mais caro do que usar o powermock. A liberação dos recursos usados ​​para o teste de unidade no banco de dados significa que a empresa não precisa atualizar o servidor o mais rápido possível.

• Confiabilidade

  Um teste pode falhar porque o banco de dados está inoperante ou em um estado inconsistente. Adivinhe, suas construções falharam porque os DBAs derrubaram o servidor de desenvolvimento durante o dia para fazer algumas atualizações (e agora os desenvolvedores estão tentando descobrir o que deu errado no código - quando não é o código).

• Manutenção adicional

  Os testes podem ser executados em qualquer ordem. Adicionar ou remover um teste não deve causar falhas no conjunto de testes. Executar em um banco de dados significa que há algum estado em algum lugar (no banco de dados). Normalmente, esses testes exigem manutenção extra para garantir que o banco de dados mantenha o estado adequado para a execução do próximo teste.

• Concorrência

  Dois desenvolvedores executam os testes de unidade ao mesmo tempo. Ter um banco de dados significa que os testes podem colidir no banco de dados. A solução para isso seria clonar o banco de dados para cada teste executado, o que é proibitivo em um banco de dados real. O que leva a outra opção a considerar.

Considere também usar o HSQLDB com qualquer dialeto do banco de dados que você estiver usando. Dessa forma, é possível criar um banco de dados na memória para cada teste. Um teste de unidade é executado, constrói o banco de dados necessário, carrega os dados, a conexão com o banco de dados do código se conecta ao HSQLDB e é executada nos dados de teste.

Minhas perguntas são: quais são os benefícios tangíveis do mundo REAL dos testes de unidade adequados que posso usar para recuar?

Bons testes de unidade são (por Código Limpo e em outros lugares):

• Rápido
• Independente
• Repetivel
• Auto-validação
• Oportuno

Não ter testes de unidade verdadeiros viola os três primeiros (e geralmente o último). Isso leva a alguns problemas bastante significativos:

1. Seus testes são lentos. Testes lentos são executados com pouca frequência. Testes que não são executados são quase inúteis.
2. Seus testes podem falhar devido a razões não relacionadas ao código que você está testando. Isso torna muito mais difícil descobrir por que os testes falharam, desperdiçando tempo e levando as pessoas a culpar o ambiente, e não o código.
3. Conforme o banco de dados muda, seus resultados mudam. Obter algum banco de dados em um estado conhecido, consistente e mantido para testes é tedioso, irritante e propenso a erros.

Em geral, a falta de isolamento nos testes de unidade leva a testes piores, que demoram mais para serem gravados, mais investidos e proporcionam menos confiança em sua base de código. Isso, por sua vez, leva as pessoas a escrever menos testes ou a ignorar mais os testes, que é a espiral descendente do caos.

Os testes de unidade são apenas uma ferramenta usada para ajudar um desenvolvedor a fornecer código confiável. Se você pensa como seu chefe pensa, será capaz de convencê-lo se o que você está propondo faz sentido. No entanto, se você apresentá-lo como evangelista em um vagão de banda, não receberá os recursos alocados. Você precisará explicar a ele como ele se beneficia gastando tempo e recursos adaptando testes de unidade ao seu aplicativo herdado.

Você mencionou testes herdados - isso implica código herdado. Infelizmente, ajustar os testes de unidade ao código que não foi projetado para ser testado é um processo difícil, demorado e caro. O business case fica ainda mais difícil se você tiver testes que fornecem resultados úteis, e tudo o que você vai conseguir são (a partir do business case POV) testes alternativos que fornecem os mesmos resultados. Você precisará se concentrar na economia de custos (tempo) .....

Meu palpite é que você não poderá apresentar ao seu chefe um caso de negócios robusto, porque não existe um.

Pelo que você descreveu, parece que você não gosta da estrutura de teste A e deseja mudar para a estrutura de teste B, as quais funcionam. Respire e use o que existe e está funcionando, não crie mais trabalho reinventando a roda para que você possa usar sua estrutura de teste preferida.

É necessário mais do que um desejo de usar a estrutura mais recente do mês para justificar o lançamento do código de trabalho existente e gastar enormes quantidades de tempo e dinheiro, beneficiando essencialmente zero dos usuários.

Bons testes de unidade fornecem localização. Os testes funcionais podem indicar que "a função adicionar usuário está interrompida", mas um bom teste de unidade informa que está quebrado porque alguém alterou o campo USER.LAST_NAME no banco de dados para não ser nulo. Também é possível testar pequenas alterações diretamente, em vez de precisar de um ambiente de teste complexo (que pode precisar ser reinicializado ou eliminado para alguns testes).