thetalkingwalnut pergunta:
Quais são algumas boas maneiras de convencer os desenvolvedores céticos da equipe sobre o valor dos testes de unidade?
Todo mundo aqui vai se amontoar em muitas razões do nada porque o teste de unidade é bom. No entanto, acho que muitas vezes a melhor maneira de convencer alguém de alguma coisa é ouvir seu argumento e abordá-lo ponto a ponto. Se você os ouvir e ajudá-los a verbalizar suas preocupações, poderá abordar cada um deles e, talvez, convertê-los ao seu ponto de vista (ou, pelo menos, deixá-los sem uma perna para se apoiar). Quem sabe? Talvez eles o convencerão por que os testes de unidade não são adequados para sua situação. Não provável, mas possível. Talvez se você postar seus argumentos em testes de unidade, podemos ajudar a identificar os contra-argumentos.
É importante ouvir e entender os dois lados da discussão. Se você tentar adotar testes de unidade com zelo demais, sem levar em conta as preocupações das pessoas, você terminará em uma guerra religiosa (e provavelmente em testes de unidade realmente inúteis). Se você adotá-lo lentamente e começar aplicando-o onde obterá o maior benefício pelo menor custo, poderá demonstrar o valor dos testes de unidade e ter uma melhor chance de convencer as pessoas. Sei que isso não é tão fácil quanto parece - geralmente requer algum tempo e métricas cuidadosas para criar um argumento convincente.
Os testes de unidade são uma ferramenta, como qualquer outra, e devem ser aplicados de forma que os benefícios (captura de bugs) superem os custos (o esforço para escrevê-los). Não os use se / onde eles não fizerem sentido e lembre-se de que eles são apenas parte de seu arsenal de ferramentas (por exemplo, inspeções, asserções, analisadores de código, métodos formais, etc.). O que digo aos meus desenvolvedores é o seguinte:
Eles podem deixar de escrever um teste para um método se tiverem um bom argumento sobre por que não é necessário (por exemplo, simples demais para valer a pena ou difícil demais para valer a pena) e como o método será verificado de outra forma (por exemplo, inspeção, afirmações) , métodos formais, testes interativos / de integração). Eles precisam considerar que algumas verificações, como inspeções e provas formais, são feitas em um determinado momento e precisam ser repetidas sempre que o código de produção for alterado, enquanto testes de unidade e asserções podem ser usados como testes de regressão (escritos uma vez e executados repetidamente posteriormente) ) Às vezes eu concordo com eles, mas com mais frequência debaterei se um método é realmente simples ou difícil demais para o teste de unidade.
Se um desenvolvedor argumentar que um método parece muito simples para falhar, não vale a pena gastar os 60 segundos necessários para escrever um teste de unidade de 5 linhas simples para ele? Essas 5 linhas de código serão executadas todas as noites (você constrói todas as noites, certo?) Durante o próximo ano ou mais e valerá a pena o esforço se, mesmo assim, ocorrer um problema que pode levar 15 minutos ou mais para identificar e depurar. Além disso, escrever os testes de unidade fáceis aumenta a contagem de testes de unidade, o que faz o desenvolvedor parecer bem.
Por outro lado, se um desenvolvedor argumentar que um método parece muito difícil para o teste de unidade (não vale o esforço significativo necessário), talvez seja uma boa indicação de que o método precisa ser dividido ou refatorado para testar as partes fáceis. Geralmente, esses são métodos que dependem de recursos incomuns, como singletons, a hora atual ou recursos externos, como um conjunto de resultados do banco de dados. Esses métodos geralmente precisam ser refatorados para um método que obtém o recurso (por exemplo, chama getTime ()) e um método que aceita o recurso como argumento (por exemplo, usa o registro de data e hora como parâmetro). Deixo que eles deixem de testar o método que recupera o recurso e, em vez disso, escrevem um teste de unidade para o método que agora utiliza o recurso como argumento. Geralmente, isso torna a escrita do teste de unidade muito mais simples e, portanto, vale a pena escrever.
O desenvolvedor precisa traçar uma "linha na areia" em como os testes de unidade devem ser abrangentes. Mais tarde no desenvolvimento, sempre que encontrarmos um bug, eles deverão determinar se testes de unidade mais abrangentes teriam detectado o problema. Nesse caso, e se esses erros surgirem repetidamente, eles precisam mover a "linha" para escrever testes de unidade mais abrangentes no futuro (começando com adicionar ou expandir o teste de unidade do bug atual). Eles precisam encontrar o equilíbrio certo.
É importante perceber os testes de unidade não são uma bala de prata e não é tal coisa a como demasiado testes de unidade. No meu local de trabalho, sempre que fazemos as lições aprendidas, inevitavelmente ouço "precisamos escrever mais testes de unidade". A gerência concorda com a cabeça, porque foi golpeado na cabeça deles que "testes de unidade" == "bom".
No entanto, precisamos entender o impacto de "mais testes de unidade". Um desenvolvedor pode escrever ~ N linhas de código por semana e você precisa descobrir qual porcentagem desse código deve ser código de teste de unidade versus código de produção. Um local de trabalho relaxado pode ter 10% do código como testes de unidade e 90% do código como código de produção, resultando em produtos com muitos recursos (embora muito problemáticos) (pense no MS Word). Por outro lado, uma loja rigorosa com 90% de testes de unidade e 10% de código de produção terá um produto sólido com muito poucas características (pense em "vi"). Você pode nunca ouvir relatórios sobre a falha do último produto, mas isso provavelmente tem muito a ver com o produto que não está vendendo muito bem e com a qualidade do código.
Pior ainda, talvez a única certeza no desenvolvimento de software seja que "a mudança é inevitável". Suponha que a loja estrita (90% de testes de unidade / 10% de código de produção) crie um produto com exatamente 2 recursos (assumindo 5% do código de produção == 1 recurso). Se o cliente aparecer e alterar 1 dos recursos, essa alteração prejudicará 50% do código (45% dos testes de unidade e 5% do código de produção). A loja relaxada (10% de testes de unidade / 90% de código de produção) possui um produto com 18 recursos, nenhum dos quais funciona muito bem. Seu cliente reformula completamente os requisitos de quatro de seus recursos. Embora a alteração seja quatro vezes maior, apenas metade da base de código é descartada (~ 25% = ~ 4,4% dos testes de unidade + 20% do código de produção).
O que quero dizer é que você precisa comunicar que entende o equilíbrio entre muito pouco e muito teste de unidade - essencialmente que você pensou nos dois lados da questão. Se você conseguir convencer seus colegas e / ou administrar isso, ganha credibilidade e talvez tenha mais chances de conquistá-los.