Como lidar com a longa duração testes de unidade?

StackOverflow https://stackoverflow.com/questions/368622

Pergunta

Eu tenho cerca de 100 testes de unidade e com uma cobertura de 20%, o que eu estou tentando aumentar a cobertura e também este é um projeto em desenvolvimento para continuar a acrescentar novos testes.

Atualmente correr meus testes após cada compilação não é viável que leva cerca de 2 minutos.

Test Inclui:

  • Arquivo ler a partir das pastas de teste (estilo impulsionado dados-para simular algumas coisas HTTP)
  • Fazer solicitações HTTP reais para um servidor web local (esta é uma enorme dor para simulada, então eu não)
  • Nem todos eles unidade-testes, mas há também muito complicado aulas multithreaded que precisam ser testados e eu testar o comportamento global do teste. Que pode ser considerado como Testes Funcionais mas precisam ser executado a cada vez também.

A maioria das funcionalidades requer leitura HTTP, fazendo TCP etc. eu não posso mudá-los porque isso é toda a idéia de projeto se eu mudar estes testes ela será inútil para o material de teste.

Além disso eu não acho que eu tenho as ferramentas mais rápidas para executar testes de unidade. Minha configuração atual usa VS TS com Gálio e nUnit como framework. Acho VS TS + Gallio é um pouco mais lento do que os outros também.

O que você recomendaria me para corrigir esse problema? Eu quero correr unidade-testes após cada pouco muda btu atualmente este problema está a interromper meu fluxo.

Esclarecimento Edit:

código é altamente acoplada! Infelizmente ea mudança é como um processo refatoring enorme. E existe uma síndrome de ovo de galinha nele onde eu preciso testes de unidade para refatorar um grande código, mas eu não posso ter mais testes de unidade, se eu não refatorar-lo:)

código altamente acoplados não me permite dividir testes em pedaços menores. Também não testar coisas particulares, é escolha pessoal, que me permita desenvolver muito mais rápido e ainda ganhar uma grande quantidade de benefícios.

E eu posso confirmar que todos os testes de unidade (com isolamento adequado) bastante rápido na verdade, e eu não tenho um problema de desempenho com eles.

Além disso Esclarecimento:

código é altamente acoplada! Infelizmente ea mudança é como um processo refatoring enorme. E existe uma síndrome de ovo de galinha nele onde eu preciso testes de unidade para refatorar um grande código, mas eu não posso ter mais testes de unidade, se eu não refatorar-lo:)

código altamente acoplados não me permite dividir testes em pedaços menores. Também não testar coisas particulares, é escolha pessoal, que me permita desenvolver muito mais rápido e ainda ganhar uma grande quantidade de benefícios.

E eu posso confirmar que todos os testes de unidade (com isolamento adequado) bastante rápido na verdade, e eu não tenho um problema de desempenho com eles.

Foi útil?

Solução

Estes não soar como testes de unidade para mim, mas mais como testes funcionais. Isso é bom, automatizar testes funcionais é bom, mas é muito comum para testes funcionais a ser lento. Eles estão testando o sistema inteiro (ou grandes partes dele).

Os testes unitários tendem a ser rápido, porque eles estão testando uma coisa isolada de tudo o resto. Se você não pode testar as coisas isoladamente de tudo o resto, você deve considerar que um sinal de alerta que você código é muito fortemente acoplados .

Você pode dizer que testa você tem que são testes de unidade (teste 1 coisa apenas) vs. testes funcionais (teste de 2 ou mais coisas ao mesmo tempo)? Os que são rápidos e quais são lentos?

Outras dicas

Você pode dividir seus testes em dois grupos, um para testes curtos e um para testes de longa duração, e executar os testes de longa execução com menos frequência durante a execução dos testes curtos após cada mudança. Fora isso, zombando as respostas do servidor web e outras solicitações a aplicação efectua levaria a uma menor test-run.

Eu recomendaria uma abordagem combinada para o seu problema:

  • passam frequentemente um subconjunto dos testes que estão perto do código que você fazer alterações (por exemplo testes do mesmo pacote, módulo ou similar). Menos frequentemente executar testes que estão mais distantes do código que você está trabalhando atualmente.
  • Dividir a sua suíte em pelo menos dois: rápida execução e testes de execução lenta. Execute os testes rápidos que funcionam com mais freqüência.
  • Considere ter alguns dos menos propensos a falhar os testes só podem ser executados por um servidor de integração automatizada continua.
  • Aprenda técnicas para melhorar o desempenho de seus testes. Mais importante, substituindo o acesso aos recursos do sistema lento por falsificações mais rápidos. Por exemplo, o uso da memória córregos em vez de arquivos. Stub / zombar do acesso http. etc.
  • Saiba como usar baixa dependência risco quebrando técnicas, como os listados na (muito altamente recomendado) livro "Trabalhando efetivamente com Legacy Code". Estes permitem que você efetivamente fazer seu código mais testável sem aplicar refatorações alto risco (muitas vezes, fazendo temporariamente o projeto real pior, como quebrar o encapsulamento, até que você pode refatorar para um melhor design com a rede de segurança de testes).

Uma das coisas mais importantes que aprendi com o livro mencionado acima: não há mágica, trabalhando com código legado é dor, e sempre será dor. Tudo o que você pode fazer é aceitar esse fato, e fazer o seu melhor para trabalhar lentamente o caminho para sair da confusão.

Em primeiro lugar, aqueles que não são testes de unidade.

Não há muito de um ponto de execução de testes funcionais, como que depois de cada pequena mudança. Após uma mudança considerável você vai querer executar os testes funcionais.

Em segundo lugar, não tenha medo de ironizar a parte Http da aplicação. Se você realmente quer teste de unidade do aplicativo é um deve. Se o seu não estão dispostos a fazer isso, você vai perder muito mais tempo tentando testar a sua lógica real, à espera de solicitações HTTP para voltar e tentar configurar os dados.

Gostaria de manter seus testes de nível de integração, mas nos esforçamos para criar testes unitários reais. Isto irá resolver seus problemas de velocidade. testes de unidade real não tem interação DB, ou HTTP interação.

Eu sempre uso uma categoria para "LongTest". Aqueles teste são executadas todas as noites e não durante o dia. Desta forma, você pode reduzir o tempo de espera por um lote. Experimente:. Categoria o seu teste de unidade

Parece que você pode precisar para gerenciar expectativas entre a equipe de desenvolvimento também.

Presumo que as pessoas estão fazendo vários constrói por dia e são epxected para executar testes após cada compilação. Você pode nos ser bem servido para mudar sua programação de testes para executar uma compilação com testes durante o almoço e, em seguida, outra noite acabou.

Eu concordo com Brad que estes som como testes funcionais. Se você pode puxar o código para além de que seria ótimo, mas até então eu mudar para testes menos frequentes.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top