quanto tempo você gasta em testes de unidade?


27

Em uma empresa em que trabalhei, os executivos insistiram que a cobertura do código com testes de unidade deve ser de 99% ou mais. Isso resultou na criação de mais testes do que código. Levamos literalmente três dias para escrever testes para uma única classe que levou um dia para ser implementada.

Como resultado, no entanto, aprendi muito sobre TDD, ferramentas de teste, práticas etc.

Na empresa em que trabalhei depois, o teste de unidade era uma coisa desconhecida. Era algo que alguém talvez já tenha ouvido antes. Eu lutei para apresentá-los ao conceito de teste de unidade, mas sem efeito.

Agora, como trabalhador por conta própria, eu me pergunto - quanto tempo é realmente necessário para gastar em testes de unidade? Sendo principalmente desenvolvedor de iPhone / Android, quais partes do código devem ser cobertas nos testes?


Na minha empresa anterior, era o Java EE, estrutura de listras e suportes. Como afirmei, agora é principalmente desenvolvimento para iPhone e Android.
Maggie

TDD significa que você escreve os testes antes do código. Parece que foi um teste "depois do fato", que é outra coisa.

os gerentes não se importaram com a técnica, meu líder de equipe insistiu no TDD. ele acabou como uma combinação de ambos :)
Maggie

Maggie, você pode achar este artigo interessante: fastcompany.com/magazine/06/writestuff.html

Existe alguma metrcis para estimar o tempo? Ferramentas para código JS / .NET?
21135

Respostas:


16

A quantidade de testes de unidade necessária depende de vários fatores:

  • Tamanho do produto (quanto maior o projeto, maior a necessidade de incluir pelo menos alguns testes de unidade)
  • Nível de qualidade exigido (se você estiver montando rapidamente o software que precisa ser lançado o mais rápido possível e alguns bugs menores forem aceitáveis, poderá ser forçado a pular alguns testes, como o teste de unidade)
  • Tipo de produto (as UIs podem ser testadas em unidade, mas às vezes é mais fácil pular o teste de unidade em seções pesadas da GUI de um projeto e, em vez disso, testar manualmente)
  • Sua capacidade / histórico de codificação (Que tipo de bugs você normalmente cria? São coisas que o Teste de Unidade normalmente captura ou coisas que outro tipo de teste normalmente encontra. Saber disso pode forçar você a fazer mais ou menos testes de unidade)

10

Em nosso grupo de produtos, visamos a cobertura de código de 50 a 70% dos testes de unidade e mais de 90% de cobertura dos testes de unidade e automação de testes combinados. O tempo típico orçado para escrever testes de unidade é de cerca de 1 dia para cada recurso que requer 3-4 dias de codificação. Mas isso pode variar com muitos fatores.

99% de cobertura de código é excelente. Os testes de unidade são ótimos. Mas 99% de cobertura de código apenas de testes de unidade? Acho difícil acreditar que você possa obter tanta cobertura apenas dos testes de unidade .

Para o caso em que você passou 3 dias escrevendo testes para uma classe que demorava 1 dia para implementar. Você não explicou por que demorou tanto tempo nem compartilhou nenhum código. Pela especulação, acho que você não estava realmente escrevendo um teste de unidade real para a sua turma, mas realmente escrevendo a automação de teste . E, na verdade, não há nada errado com isso - desde que você reconheça a diferença entre os dois tipos diferentes de testes.

Mas você disse que os três dias de escrita de teste eram apenas para uma única aula. Talvez a própria classe não tenha sido projetada para testes de unidade. A classe implementa interface do usuário? Networking? Arquivo E / S? Nesse caso, você pode ter acabado escrevendo mais código para testar o tempo de execução Java do que sua lógica de negócios que interage com o tempo de execução.

O TDD faz você pensar em termos de interfaces e interfaces para dependências. Essa classe única que implementa interface do usuário, rede e arquivo / io para um único recurso pode ser melhor servida dividida em várias classes - uma para rede, outra para arquivo / io e a interface do usuário dividida em um design de visualizador-controlador-modelo. Em seguida, você pode implementar testes apropriados para cada um com objetos simulados simples para as dependências. Claro, tudo isso leva mais tempo. Portanto, em vez de 1 dia para codificar e 3 dias para escrever testes, esse tipo de design pode exigir 3 dias de codificação e 1 dia de testes de gravação. Mas o código será muito melhor de manter e reutilizar.


1
Ótima resposta. A maior parte foi muito complicada para testes, você está certo sobre isso. E dividir a classe em várias unidades menores apenas para se adequar a melhores testes de unidade parece um pouco exagerado. Adoraria anexar o código para a classe e os testes associados, e adoraria ouvir sua opinião, mas não tenho certeza se tenho permissão para isso. O código não é estritamente meu, e eu não trabalho mais para essa empresa, então gostaria de evitar problemas.
Maggie

2
É por isso que você deve escrever os testes primeiro. Então você pode encontrar os lugares naturais onde a lógica se cola.

10

Os testes de unidade são recompensados ​​no momento da manutenção. Se você planeja ter um aplicativo de longa duração, gastará mais tempo mantendo do que pensa agora (se ainda não o tiver experimentado, ficará surpreso quanto tempo durar um projeto bem-sucedido).

O que você deseja é que, se você mudar acidentalmente sua funcionalidade, seus testes serão interrompidos para que você encontre essas coisas o mais rápido possível. Os clientes não gostam muito quando a funcionalidade muda inesperadamente.


3
E você ficar mal quando você corrigir bug A apenas para introduzir bugs B & C.
Jeffo

depende se B e C são capturados por testes ou não

"você gastará mais tempo mantendo o que pensa agora" - de fato, especialmente levando em consideração que os produtos SW geralmente sobrevivem à vida útil planejada, muitas vezes de longe.
Péter Török

Você realmente não pode "planejar" ter uma aplicação de longa duração, pois não pode dizer com antecedência se o projeto será bem-sucedido ou não. Você deve sempre considerar que quando o tempo de orçamento para testes
Eran Galperin

1
@ Eran, então você deve planejar a falha para não precisar fazer um orçamento para testes?

4

Se você estiver fazendo TDD, estará escrevendo os testes ao mesmo tempo que o código, alternando entre eles a cada poucos minutos (ou menos). Não haverá tempo distinto gasto para os testes. O uso do TDD facilita muito saber que você tem uma cobertura sólida de teste.

Se você estiver testando a unidade após o fato, precisará escrever os testes que informarão se o código está quebrado devido a alterações. Eu não confiaria nas métricas de cobertura aqui, mas basear-me-ia em casos de uso e parâmetros para interfaces públicas. Em última análise, isso será baseado no seu bom gosto e experiência.


Sim, para mim isso é verdade (na verdade, eu geralmente alterno entre trabalhar nos testes e trabalhar no código do produto a cada poucos segundos , não minutos). Portanto, estou trabalhando nos testes 100% do tempo.
Jonathan Hartley

2

Se você não gastar tempo em testes, gastará ainda mais tempo para depurar no código ativo.
Portanto, gaste o tempo necessário para testar, para cobrir todos (ou 99% do código).


4
Por que as pessoas têm tanta paranóia de depuração? Se você conhece as ferramentas, raramente encontra um problema que leva mais de 5 minutos para depurar. Os problemas difíceis de depurar estão principalmente relacionados ao encadeamento, mas os testes de unidade são inúteis de qualquer maneira.
Coder

3
@ Codificador, porque as pessoas têm experiência e sabem que os testes são uma coisa muito mais útil do que a depuração às cegas.
OZ_

2
Depende. Os testes de unidade geralmente são contraproducentes e acrescentam uma falsa sensação de segurança. E em código bem estruturado, você não entrará no problema da "depuração cega". Você tem um problema, sabe onde procurar. Caso contrário, faça uma revisão completa do código / design. Veja também: programmers.stackexchange.com/questions/86636/…
Coder

4
Esse é o problema de muitos defensores do TDD, eles têm uma postura hostil contra a depuração e o design, enquanto confiam nos testes para encontrar todos os bugs. Em seguida, no código de produção, os aplicativos vazam memória, identificadores e travam em vários núcleos e são como? WTH ?. O TDD é apenas uma ferramenta e, dependendo da tarefa em questão, pode ser muito produtivo ou muito contraproducente. Tente escrever testes de unidade para todos os casos difíceis na postagem vinculada e você nunca enviará o produto.
Coder

1
"Se você conhece as ferramentas, raramente encontra um problema que leva mais de 5 minutos para depurar." - @Coder Gostaria de saber que tipo de aplicativos você está vendo.
precisa

2

Como outros já observaram, isso depende muito do tipo de software. A proporção de tempo de teste / desenvolvimento de 3: 1 mencionada pode ser um pouco demais para projetos comuns, mas pode ser perfeitamente aceitável para aplicativos de missão crítica e pode ser insuficiente para um sistema de vida útil.

Uma cobertura de teste de unidade de mais de 99% é similarmente talvez demais para esperar no caso de um aplicativo comum, mas muito pouco para um projeto essencial à vida.

Na minha experiência, considerando que uma parte significativa do código de produção é um código de manipulação de erros, uma cobertura de 80 a 90% seria suficiente para a maioria dos aplicativos, e isso poderia exigir aproximadamente a mesma quantidade de tempo gasto escrevendo testes de unidade que o código de produção. (Então, novamente, se alguém está trabalhando seriamente no estilo TDD, os dois estão completamente entrelaçados para se tornar praticamente uma única tarefa, para que se possa estimar apenas a proporção real.)


você tem experiência em aplicativos móveis? qual seria uma relação aceitável de teste / desenvolvimento para um aplicativo móvel simples?
Maggie

@ Maggie, infelizmente não. (Então, se eu precisava para escrever um, eu provavelmente iria gastar mais do meu tempo habitual sobre os testes de unidade :-)
Péter Török
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.