quanto tempo você gasta em testes de unidade?

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?

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)

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.

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.

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.

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).

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.)