O teste de unidade de velocidade de execução (como muitos testes por segundo?)

https://stackoverflow.com/questions/10486

08-06-2019
|

Pergunta

Que tipo de taxa de execução, você apontar para com seus testes de unidade (# teste por segundo)?Quanto tempo é longo demais para um indivíduo de teste de unidade?

Eu estaria interessado em saber se as pessoas têm qualquer limiares específicos para determinar se os seus testes são muito lentas, ou é só quando o atrito de uma longa suite de teste obtém o melhor de você?

Finalmente, quando você decidir fazer os testes precisam correr mais rápido, quais as técnicas que você usa para acelerar os testes?

Nota:testes de integração são, obviamente, uma questão diferente novamente.Nós, estritamente falando de testes de unidade que precisa ser executado como frequentemente quanto possível.

Resposta roundup: Obrigado pelas ótimas respostas até agora.A maioria dos conselhos parece não se preocupar com a velocidade -- se concentrar em qualidade e apenas seletivamente executá-los se eles são demasiado lentos.Respostas com números específicos incluíram apontando para <10ms até 0,5 e 1 segundo por teste, ou apenas manter-se a todo um conjunto de comumente a execução de testes em 10 segundos.

Não tenho certeza se é certa a marca como um "aceito resposta" quando eles são todos muito útil :)

Solução

Todos os testes de unidade devem ser executados em menos de um segundo (que é de todos os testes de unidade combinada deve ser executado em 1 segundo).Agora eu tenho certeza que isso tem limites práticos, mas eu já tinha um projeto com 1000 testes que são executados rápido em um laptop.Você realmente deseja esta velocidade, de modo que seus desenvolvedores não dread refatoração alguns núcleo faz parte do modelo (por exemplo, Vou ir tomar um café enquanto eu executar estes testes...10 minutos depois, ele volta).

Este requisito também força você a projetar seu aplicativo corretamente.Isso significa que o modelo de domínio é pura e contém zero referências a qualquer tipo de persistência (e/S de Arquivo, Banco de dados, etc.).Testes de unidade são todos os cerca de testar as pessoas com de negócios relatonships.

Agora, o que não significa ignorar o teste de seu banco de dados ou de persistência.Mas estes problemas agora são isolados atrás de repositórios que podem ser separadamente testado com testes de integração que está localizado em um projeto separado.Executar os testes de unidade constantemente ao escrever código de domínio e, em seguida, executar os seus testes de integração de uma vez no check-in.

Outras dicas

Se estamos falando estritamente testes de unidade, eu apontaria mais para a completude do que a velocidade.Se o tempo de execução começa a causar atrito, separar o teste em diferentes projecto/classes etc., e só executar os testes relacionados ao que você está trabalhando.Permitir que o servidor de Integração executar todos os testes no checkin.

O objetivo é 100s de testes por segundo.A maneira de chegar lá é a seguinte, Michael Pena do regras de testes de unidade.

Um ponto importante que surgiu em um passado CITCON discussão é que, se os testes não são este rápido, é muito provável que você não estiver recebendo os benefícios de design de testes de unidade.

Eu tendem a se concentrar mais na legibilidade dos meus testes de velocidade.No entanto, eu ainda tento fazê-los razoavelmente rápido.Eu acho que se eles serão executados na ordem de milissegundos, você está muito bem.Se executar uma segunda ou mais por teste...em seguida, você pode estar fazendo algo que deve ser otimizado.

Lenta testes apenas tornar-se um problema a medida que o sistema amadurece e faz com que a compilação levar horas, altura em que é mais provável que você executar em um problema de um monte de tipo de lenta testes, ao invés de incluir um ou 2 testes que você pode otimizar facilmente...assim, provavelmente, você deve prestar atenção imediatamente se você ver um monte de testes com centenas de milissegundos (ou pior, segundos cada), em vez de esperar até que começa a centenas de testes, tendo que long point (ponto no qual ela vai ser muito duro para resolver o problema).

Mesmo assim, ele só vai reduzir o tempo entre o momento de sua criação automática de problemas de erros de...o que é ok se é uma hora mais tarde (ou até mesmo algumas horas mais tarde), eu acho.O problema é a execução-los antes do check-in, mas isso pode ser evitado através da seleção de um pequeno subconjunto de testes a executar, que estão relacionados ao que você está trabalhando.Apenas certifique-se de corrigir a compilação se você verificar o código que quebras de testes que você não corra!

Estamos atualmente em 270 testes em torno de 3.algo segundos.Há provavelmente cerca de 8 testes que realizar e / s de arquivo.

Estes são executados automaticamente após uma compilação bem-sucedida de nossas bibliotecas em todos os engenheiros de máquina.Temos mais extenso (e demorado) fumaça-teste que é feito pela máquina de compilação, a cada noite, ou pode ser iniciado manualmente em uma engenheiros máquina.

Como você pode ver, nós ainda não atingiu o problema de testes de ser muito demorado.10 segundos, para mim, é o ponto onde ele começa a se tornar invasivo, quando começamos a abordagem que vai ser algo que nós vamos dar uma olhada.Nós provavelmente iremos mover o menor nível de bibliotecas, que são mais robustos, uma vez que raramente mudam e tem poucas dependências, no nightly builds, ou uma configuração onde são executadas apenas pela máquina de compilação.

Se você demorar mais do que alguns segundos para ser executado mais de uma centena de testes que você pode precisar examinar o que você está classificando como um teste de unidade e se seria melhor tratado como um teste de fumo.

sua milhagem vai, obviamente, ser altamente variável dependendo de sua área de desenvolvimento.

Ponto De Dados -- Python Testes De Regressão

Aqui estão os números no meu laptop para a execução de "fazer teste" para Python 2.5.2:

número de testes:3851 (aprox)
tempo de execução:9 min 6 sec
taxa de execução:7 testes / s

Eu julgar a minha testes de unidade por base de amostragem, não pelo número de testes por segundo.A taxa meu objetivo é 500ms ou menos.Se ele está acima, eu vou olhar para o teste para descobrir por que ele está demorando tanto.

Quando eu acho que um teste é lento, isso normalmente significa que ele está fazendo muito.Portanto, apenas reescrevendo o teste dividindo-o em mais testes normalmente faz o truque.As outras vezes que eu observei meus testes lento, é quando o teste mostra um gargalo no meu código, em seguida, uma refatoração de código está em ordem.

Houve um bom artigo nesta partir de Potência De Dois jogos, os autores do UnitTest++.

Quanto tempo é longo demais para um indivíduo teste de unidade?

Eu diria que depende a velocidade de compilação.Geralmente executa os testes em cada compilação.O objetivo do teste de unidade não é lento, mas para trazer uma mensagem "nada quebrado, vá em"(ou "algo quebrou, PARAR").

Eu não me incomodo sobre a execução do teste de velocidade até que isso é algo que começa a ficar chato.

O perigo é deixar de executar os testes, porque eles são muito lentos.

Finalmente, quando você decidir fazer os testes precisa correr mais rápido, o que as técnicas de você usar para acelerar seus testes?

Primeira coisa a fazer é gerenciar para descobrir por que eles são muito lentas, e se o problema é no testes de unidade ou no código em teste ?

Eu gostaria de tentar quebrar o conjunto de teste em várias partes lógicas, executando apenas a parte que está supostamente afetado pelo código que mudou em cada compilação.Eu ia correr para o outro suites com menos frequência, talvez uma vez ao dia, ou quando em dúvida, eu poderia ter quebrado alguma coisa, e pelo menos antes de integrar.

Alguns frameworks fornecem execução automática específicos, testes de unidade com base na heurística tal como modificado de última hora.Para Ruby e Rails, AutoTest fornece muito mais rápido e ágil de execução dos testes, quando eu salvar um modelo Trilhos app/models/foo.rb, o correspondente testes de unidade em test/unit/foo_test.rb obter executar.

Eu não sei se algo semelhante existe para outras plataformas, mas faria sentido.

Uma das regras mais importantes sobre testes de unidade é que eles devem executar rápido.

Quanto tempo é longo demais para um indivíduo de teste de unidade?

Os desenvolvedores devem ser capazes de executar todo o conjunto de testes de unidade em segundos, e, definitivamente, não em minutos e os minutos.Os desenvolvedores devem ser capazes de rapidamente se executa-los depois de alterar o código em qualquer forma.Se ele demora muito, eles não se incomodam de executá-los e você perde uma das principais vantagens dos testes.

Que tipo de taxa de execução, você apontar para com seus testes de unidade (# teste por segundo)?

Você deve apontar para cada teste a ser executado em uma ordem de milissegundos, nada mais de 1 segundo é, provavelmente, o teste muito.

Atualmente, temos cerca de 800 testes que são executados em menos de 30 segundos, cerca de 27 de testes por segundo.Isso inclui o tempo para iniciar o celular emulador necessário para executá-los.A maioria deles, cada um leva 0-5ms (se eu me lembro corretamente).

Temos um ou dois que leva cerca de 3 segundos, que são, provavelmente, os candidatos para a verificação, mas o importante é todo o conjunto de teste não leva tanto tempo que ele coloca fora de desenvolvedores de execução, e não retardar significativamente a nossa integração contínua, build.

Nós também temos um limite de tempo configurável limite definido para 5 segundos -- nada de mais vai falhar.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow