Como convencer um patrocinador do projeto de que todas as funções do seu código devem ter testes unitários [fechado]

Question

Na maioria dos casos, pessoas não técnicas não veem nenhum valor em escrever testes unitários.Eles só querem ter o código básico concluído e não gastam tempo e dinheiro em coisas como testes de unidade.Mais tarde, todos os dias eles só pedem para consertar mais um bug.Os projetos estão perdendo prazos e ainda não veem valor em bons testes automatizados.

Answer 1

A melhor maneira é não ser tão técnico com pessoas “não técnicas”.Basta incluir no prazo de entrega sem entrar em detalhes.

Por outro lado, parece que os prazos do projeto não eram realistas para realmente construí-lo.

Answer 2

Eu acabei de escreveu longamente sobre este mesmo assunto.

Para resumir meus argumentos contra as reclamações comuns:

A limpeza é invisível para os usuários;precisamos adicionar novos recursos.Os bugs constantemente produzidos por códigos confusos também são visíveis para os usuários.O tempo gasto na correção desses bugs poderia ter sido gasto na adição de recursos.Quanto mais tempo permanecemos em dívida de qualidade, mais tempo leva para adicionar cada novo recurso.

Não temos tempo para limpeza.Você prefere gastar seu tempo corrigindo bugs gerados pelo problema em vez de corrigi-lo?É como arrancar ervas daninhas todo fim de semana, em vez de arrancá-las pela raiz.A prevenção é dezesseis vezes mais valiosa do que a cura.

Os desenvolvedores se meteram nessa confusão;eles deveriam sair disso em seu próprio tempo.Se os desenvolvedores não tivessem lançado os lançamentos tão rapidamente quanto o fizeram, se não tivessem respondido tão rapidamente ao feedback dos primeiros usuários, mesmo quando o produto se transformou em uma fera bem diferente de sua concepção original, não teríamos nossos clientes e receitas atuais .Estaríamos trabalhando para outra empresa e não reclamando do software que construímos.

Atenção CEOs:Apontar o dedo impede a resolução.Em vez disso, desafie seus desenvolvedores a reduzir os relatórios de bugs.Isso é facilmente medido, para que você possa acompanhar o tempo versus os resultados.Lembre-se de que os desenvolvedores preferem implementar novos recursos a corrigir bugs; portanto, se eles estão implorando por tempo para corrigir bugs, isso é sério.

Answer 3

Tente usar um analógico.Pergunte se eles gostariam que seus filhos dirigissem Volvos ou Kit cars feitos por algum cara na rua.A resposta deve ser sempre o Volvo.Então pergunte por quê?A resposta é que é mais confiável e seguro.Como eles sabem.A resposta é testar.Todos os automóveis são testados ao extremo e o custo reflete isso.Se eles desejam que o software seja o mais confiável possível, eles precisam de testes.(Ou eles se tornam bonecos de teste de colisão)

Answer 4

Bem, acho que o problema é que você diz "todas as funções".Todas as funções não precisam de testes unitários, e alguns argumentariam que testar unidades de funções individuais é totalmente errado em muitos cenários.

Em vez disso, recomendo testar unidades reais de "unidades de funcionalidade".Em vez de escrever um único teste para cada função, escreva um teste para cada cenário ou recurso.Além de economizar muito tempo e permitir que você passe despercebido nos testes, muitas vezes é muito mais preciso porque testa literalmente as funções da maneira como estão sendo usadas.Muitas vezes, os testes de unidade de função não testam a coisa certa ou, pior ainda, testam simulações.

Eu recomendo que você evite usar simulações em testes a todo custo.O uso de uma simulação invalida essencialmente o teste porque você está testando como ele funciona em circunstâncias idealizadas, em vez de como funciona no mundo real.

Um benefício colateral é que você também obtém melhor detecção de código morto.Qualquer código que não seja coberto por um teste de alto nível provavelmente não está sendo usado e pode ser removido.Nunca subestime o valor da eliminação do código morto.

Answer 5

Vender testes unitários completos após o desenvolvimento já ter começado é muito duro.Eu chegaria ao ponto de dizer que muitas vezes é impossível.Se você não conseguir a adesão de todas as partes interessadas do projeto para testes de unidade completos antecipadamente, ficará feliz com qualquer teste de unidade que puder realizar.

Answer 6

Você não.Os testes não devem ser escritos separadamente, portanto, não há mais necessidade de considerá-los no cronograma do que você agendaria especificamente a "compilação" ou a "digitação do código".Qualquer tempo gasto escrevendo os testes deve ser compensado pelo tempo que eles economizam de qualquer maneira.

Answer 7

Apenas faça.Você será mais lento no início, pois escreverá mais código e pensará no problema primeiro.Mas você rapidamente ultrapassará outros no projeto, pois terá menos erros/bugs e seu design será melhor.

Se você projetar o sistema tendo em mente o teste, ele será inerentemente mais flexível do que um projeto não testável.Será então mais rápido adicionar recursos no futuro.

Answer 8

@Craig, pensei no analógico do carro também, mas acho que a analogia desmorona, pois parece que já existem testes presentes no projeto e é simplesmente uma questão de grau.Nesse caso, a analogia do carro torna-se "Você se importa se a luz do teto do carro for testada, desde que os sistemas críticos (freios, faróis, transmissão, etc.) sejam testados".Como um patrocinador de projeto apressado que está vendo o projeto ultrapassar a data de término, eu realmente não me importo se a luz do teto será testada ou não.

Answer 9

Uma boa maneira de vender o valor dos testes unitários é do ponto de vista de suporte - se você estiver usando uma estrutura de testes unitários que possui um tempo de execução que pode ser implantado (nUnit é um deles), você pode ter um item de menu "Executar testes unitários" no seu menu de ajuda.Isso pode executar todos os testes de unidade e os resultados podem ser enviados ao suporte técnico para ajudar a depurar problemas do cliente.

Obviamente, há muitas maneiras de vender a maior estabilidade, mas o suporte técnico é um custo de “dinheiro real” que a maioria dos gestores gostaria de reduzir.