Quanto tempo devemos geralmente gastar escrevendo testes de unidade para um novo recurso ou correção de bugs?

9

Quando tenho que implementar um novo recurso ou corrigir um erro, geralmente tento recriar a situação com um teste. Às vezes, passo cerca de três horas inventando equipamentos e escrevendo o teste. A implementação real do recurso ou a correção de erros leva menos de 1 hora.

Alguém lá fora gasta pelo menos três vezes mais tempo para escrever um teste do que realmente implementar um recurso ou corrigir um bug? Qual é a proporção aceitável de tempo gasto escrevendo teste para escrever código?

unit-testing

— Thierry Lam
fonte

2

Pense da seguinte maneira: a correção do bug levaria menos de uma hora se você não tivesse um teste para confirmar que existia, muito menos foi corrigido?

— Michael K

2

Resposta ao título da pergunta: Quanto tempo for necessário.

— Marcelo

3

Penso que a obediência servil aos princípios do TDD, independentemente do custo ou do valor comercial, é sempre a resposta certa.

— Jeremy

Como você lida com o caso em que seu gerente deseja que você coloque a correção em funcionamento o mais rápido possível e mal pode esperar por um dia extra para testar completamente a implementação?

— Thierry Lam

2

Geralmente eu explico o custo de não fazer o teste. Ou seja, eu posso enviar a correção agora, mas se não escrevermos o teste, teremos que fazer tudo novamente mais tarde. Algumas vezes eles concordam com esse custo futuro, mas geralmente escrevemos os testes.

— Christopher Bibbs

12

Isso varia de acordo com a complexidade do bug ou recurso. Lembro-me de um projeto que já teve uma estimativa do tempo de desenvolvimento de 1,5 semana ... e uma estimativa de teste de 3 meses. A mudança de código foi pequena, várias linhas aqui e ali, mas impactou vários componentes de um sistema de seguro de várias maneiras, por isso teve que ser testada minuciosamente. Outra vez houve um erro que envolvia um parêntese no lugar errado. Levou 2 horas para encontrá-lo, 2 segundos para corrigi-lo, mas cerca de uma semana para testar dezenas de cenários que podem ter sido afetados pela mudança na lógica.

Em geral, não me preocupo com a proporção de tempo gasto em codificação e tempo gasto em testes, porque simplesmente não há como ser preciso. Acho que em alguns projetos, uma proporção relativa do projeto aparece normalmente padrão (para o projeto), mas mesmo assim isso pode mudar mais tarde.

Passe o tempo necessário para dizer com confiança que o código funciona corretamente.

— FrustratedWithFormsDesigner
fonte

6

Que tal você gastar tempo suficiente escrevendo os testes até mostrar que o recurso funciona conforme o esperado ou que o bug foi corrigido corretamente.

Toda situação será diferente; não pode haver algum tipo de proporção. Alguns testes levam um décimo do tempo que a implementação, outros levam centenas de vezes mais.

— edA-qa mort-ora-y
fonte

Esta é a verdadeira resposta.

— precisa

4

Certa vez, fiz uma fiscalização depois de introduzir testes de unidade em um projeto. O resultado: o tempo gasto escrevendo testes foi cerca de 40% novamente, tanto quanto o tempo gasto implementando. Mas não almejávamos uma cobertura completa por lá, e era um projeto bem estabelecido, com estrutura e convenções fortes.

— Michael Borgwardt
fonte

3

Eu diria que a codificação de tempo versus os testes de unidade de gravação de tempo devem ser aproximadamente iguais. Talvez um pouco mais às vezes. Dê uma olhada neste artigo sobre SO Proporção de tempo gasto em codificação versus teste de unidade

— TomHarrigan
fonte

0

Você está contando certo? Para fazer uma contabilidade precisa de quanto tempo você gasta nos testes, você precisa escrever o código sem o teste.

Se você realmente levou três horas para escrever o teste e uma para escrever o código para que ele passasse, você pode achar que leva mais de 5 horas para corrigir o mesmo bug sem escrever testes.

Sim, muitas vezes passo muito mais tempo no teste do que o código de correção real.

— Edward Strange
fonte