Preciso de teste de unidade se já tiver teste de integração?

41

Se eu já tiver um teste de integração para o meu programa, e todos eles passarem, tenho a sensação de que funcionará. Então, quais são as razões para escrever / adicionar testes unitários? Como eu já tenho que escrever testes de integração de qualquer forma, vou apenas escrever testes unitários para partes que não são cobertas por testes de integração.

O que eu sei sobre o benefício do teste unitário sobre o teste de integração é

  • Pequeno e, portanto, rápido de rodar (mas adicionar uma nova unidade para testar algo já foi testado pelo teste de integração significa que meu teste total fica maior e mais longo para ser executado)
  • Localize o bug mais fácil porque ele testa apenas uma coisa (mas posso começar a escrever teste de unidade para verificar cada parte individual quando o teste de integração falhar)
  • Encontre um bug que talvez não seja detectado no teste de integração. por exemplo. mascaramento / compensação de bugs. (mas se a minha integração testar todos os passes, o que significa que o meu programa funcionará até mesmo algum bug oculto existe. Portanto, localizar / corrigir esses bugs não são realmente de alta prioridade, a menos que eles quebrem testes de integração futuros ou causem problemas de desempenho)

E sempre queremos escrever menos código, mas os testes de unidade de gravação precisam de muito mais código (principalmente objetos simulados de configuração). A diferença entre alguns dos meus testes de unidade e testes de integração é que, em testes de unidade, uso mock object e, em testes de integração, uso o objeto real. Que tem muita duplicação e eu não gosto de código duplicado, mesmo em testes, porque isso adiciona sobrecarga para alterar o comportamento do código (ferramenta refactor não pode fazer todo o trabalho o tempo todo).

    
por Bryan Chen 14.07.2013 / 13:55
fonte

5 respostas

28

Você apresentou bons argumentos a favor e contra o teste de unidade. Então você tem que se perguntar, " Eu vejo valor nos argumentos positivos que superam os custos nos negativos? " Eu certamente faço:

  • O small-and-fast é um bom aspecto do teste de unidade, embora não seja o mais importante.
  • O localizando-bug [s] -easier é extremamente valioso. Muitos estudos de desenvolvimento de software profissional mostraram que o custo de um bug aumenta acentuadamente à medida que envelhece e desce pelo canal de entrega de software.
  • Encontrar bugs mascarados é valioso. Quando você sabe que um determinado componente tem todos os seus comportamentos verificados, você pode usá-lo de maneiras que não foram usadas anteriormente, com confiança. Se a única verificação for por meio do teste de integração, você só sabe que o atual se comporta corretamente.
  • Mocking é caro em casos do mundo real, e a manutenção de zombarias é duplamente. De fato, ao zombar de objetos ou interfaces "interessantes", você pode até precisar de testes que verifiquem se seus objetos simulados modelam corretamente seus objetos reais!

No meu livro, os profissionais superam os contras.

    
por 14.07.2013 / 15:22
fonte
8

Não vejo muito valor em reimplementar um testcase de integração existente como um teste de unidade.

Os testes de integração são muito mais fáceis de escrever para aplicativos legados não-tdd, porque geralmente as funcionalidades a serem testadas são strongmente acopladas, portanto as unidades de teste isoladas (= teste unitário) podem ser difíceis / caras / impossíveis.

> Then what are the reasons to write/add unit tests?

Na minha opinião, o desenvolvimento orientado a testes é mais eficaz se você escrever os testes de unidade antes do código real. Desta forma, o código que preenche os testes torna-se claramente separado com um mínimo de referências externas que é facilmente testável.

Se o código já existe sem os testes de unidade, geralmente é muito trabalho extra escrever os testes de unidade depois, porque o código não foi escrito para testes fáceis.

Se você faz o TDD, o código é automaticamente testável.

    
por 14.07.2013 / 16:38
fonte
5

Os testes de integração devem apenas verificar se vários componentes estão funcionando como esperado. Se a lógica dos componentes individuais é precisa ou não deve ser verificada por testes de unidade.
A maioria dos métodos tem vários caminhos de execução possíveis; pense em variáveis de entrada do if-then-else com valores inesperados ou simplesmente errados, etc. Normalmente, os desenvolvedores tendem a pensar apenas no caminho feliz: o caminho normal que não dá errado. Mas, no que diz respeito a esses outros caminhos, você tem duas opções: permitir que o usuário final explore esses caminhos por meio das ações realizadas na interface do usuário e espere que eles não travem seu aplicativo ou você pode escrever testes de unidade que afirmam o comportamento desses outros caminhos e agir quando necessário.

    
por 15.07.2013 / 12:31
fonte
4

Algumas das razões que você apontou em sua pergunta são realmente importantes e por si só poderiam muito bem fazer o caso em favor de testes unitários, mas YMMV. Por exemplo, com que frequência você executa seu conjunto de testes integrado? Minha experiência com testes integrados é que, mais cedo ou mais tarde, eles ficam tão lentos que você não os executará toda vez que fizer uma alteração, e o tempo entre a inserção e a detecção de um bug aumentará.

Além disso, um grande erro que você pode estar cometendo é confiar que

Find bug that may not be caught in integration test. e.g. masking/offsetting bugs.

não é importante. Você está esperando que seus usuários encontrem os bugs para você? Confiar em coberturas obtidas a partir de testes integrados é perigoso, na minha opinião, é muito fácil obter uma alta porcentagem de cobertura, mas na realidade você está testando muito pouco.

Eu acho que a referência canônica contra testes integrados são os posts de JBrains:

link

caso você não os tenha lido ainda.

Finalmente, IMO o feedback que você pode obter dos testes de unidade para o seu projeto é inestimável. Julgar um design pelo instinto e confiar em testes integrados também pode ser um erro.

    
por 14.07.2013 / 23:40
fonte
1

Se você espera que alguma vez precise modificar ou refatorar seu código, é essencial ter testes de unidade. Testes de unidade existem não apenas para demonstrar erros no momento em que o código é escrito, mas para mostrar quando novos bugs aparecem quando mais código é escrito.

Sim, é muito melhor escrever primeiro seus testes de integração e unidade, mas há muito valor em tê-los, mesmo que sejam escritos mais tarde.

    
por 14.07.2013 / 23:53
fonte