Então você já ouviu isso muitas vezes daqueles que não entendem verdadeiramente os valores dos testes. Só para começar, sou seguidor do Agile and Testing ...
Recentemente, tive uma discussão sobre a realização de TDD em uma reescrita de produto, onde a equipe atual não pratica testes de unidade em nenhum nível e provavelmente nunca ouviu falar da técnica de injeção de dependência ou dos padrões / design de testes etc. (nem sequer conseguiremos para limpar o código).
Agora, sou totalmente responsável pela reescrita deste produto e disseram-me que, ao tentar com o TDD, apenas o tornará um pesadelo de manutenção e impossível para a equipe manter. Além disso, como é um aplicativo front-end (não baseado na Web), a adição de testes é inútil, à medida que a unidade de negócios muda (por alterações, elas significam melhorias, é claro), os testes ficarão desatualizados, outros desenvolvedores que acessarem o projeto no futuro não os manterá e se tornará mais um fardo para eles consertarem etc.
Eu posso entender que o TDD em uma equipe que atualmente não possui nenhuma experiência de teste não parece bom, mas meu argumento neste caso é que eu posso ensinar minha prática para aqueles que estão ao meu redor, mas mais ainda, eu sei que o TDD torna MELHOR Programas. Mesmo que eu produzisse o software usando TDD e jogasse fora todos os testes ao entregá-lo a uma equipe de manutenção, certamente seria uma abordagem melhor do que não usar o TDD desde o início?
Fui abatido por ter mencionado TDD na maioria dos projetos para uma equipe que nunca ouviu falar dele. O pensamento de "interfaces" e de construtores de DI de aparência estranha os assusta ...
Alguém por favor pode me ajudar no que normalmente é uma conversa muito curta de tentar vender TDD e minha abordagem às pessoas? Normalmente, tenho uma janela de argumentação muito curta antes de cair de joelhos para a empresa / equipe.
Respostas:
Você não pode vencer esse argumento. Eles estão inventando isso. Infelizmente, você também não tem fatos reais. Qualquer exemplo que você fornecer pode ser contestado.
A única maneira de fazer essa observação é ter um código com custo mais baixo de manutenção.
Todo mundo diz isso. Também pode ser parcialmente verdade. Se o aplicativo for razoavelmente bem projetado, o front-end fará muito pouco.
Se o aplicativo for mal projetado, no entanto, o front-end faz muito e é difícil de testar. Este é um problema de design, não um problema de teste.
Este é o mesmo argumento acima.
Você não pode vencer a discussão. Então não discuta.
"Sou totalmente responsável pela reescrita deste produto"
Nesse caso,
Adicione testes de qualquer maneira. Mas adicione testes à medida que avança, de forma incremental. Não gaste muito tempo fazendo testes escritos primeiro. Converta um pouco. Teste um pouco. Converta um pouco mais. Teste um pouco mais.
Use esses testes até que alguém descubra que o teste está funcionando e pergunte por que as coisas vão tão bem.
Eu tive o mesmo argumento em uma reescrita (de C ++ para Java) e simplesmente usei os testes, mesmo que eles me dissessem que não.
Eu estava desenvolvendo muito rapidamente. Pedi exemplos concretos de resultados corretos, que eles enviaram em planilhas. Transformei as planilhas em unittest.TestCase (sem avisar) e as utiliza para testar.
Quando estava no teste de aceitação do usuário - e foram encontrados erros - eu apenas pedi que as planilhas com os exemplos fossem revisadas, corrigidas e expandidas para cobrir os problemas encontrados durante o teste de aceitação. Transformei as planilhas corrigidas em unittest.TestCase (sem avisar) e as utiliza para testar.
Ninguém precisa saber em detalhes por que você é bem sucedido.
Apenas seja bem sucedido.
fonte
Você só pode convencer essas pessoas (se é que existe) do ponto de vista prático, demonstrando o valor do TDD na vida real. Por exemplo, tomando alguns erros recentes como exemplo e mostrando como construir um teste de unidade que garante 100% de que esse erro nunca mais seja exibido. E, é claro, escreva mais uma dúzia de testes de unidade para impedir que toda a classe de erros semelhantes apareça (e quem sabe, talvez no caminho até descubra mais alguns erros inativos no código).
Se isso não funcionar no curto prazo, você precisará trabalhar nisso por mais tempo, simplesmente fazendo TDD e escrevendo testes de unidade diligentemente em suas próprias tarefas. Em seguida, compile algumas estatísticas simples após mais ou menos meio ano (se possível no seu ambiente) para comparar taxas de erros em códigos / tarefas realizadas por diferentes desenvolvedores (anonimizados para evitar alienar seus colegas de equipe). Se você pode apontar que houve significativamente menos erros encontrados no seu código do que nos outros, você pode ter um ponto forte para vender tanto para gerenciamento quanto para outros desenvolvedores.
fonte
Você precisa ser prático sobre essas coisas, o TDD é uma coisa boa a ter em teoria, mas, a menos que você esteja atualizando seus testes para tudo o que é adicionado, há pouco sentido - ninguém quer executar um teste que relata falhas código quando é o teste que não foi atualizado! Como resultado, pode ser muito caro fazê-las - você não será o único desenvolvedor trabalhando nesse código.
O cliente tem uma equipe de teste ... bem, não há problema em transferir a carga de teste do desenvolvedor para os testadores - é para isso que eles estão lá, afinal, e se encontrarem erros nos testes (talvez eles tenham muitos ferramentas de teste automatizadas), então não faz sentido escrever testes de unidade no seu nível. Levará um pouco mais de tempo para encontrar os bugs, mas eles encontrarão aqueles bugs irritantes de "integração" que seus testes não teriam exercido.
Provavelmente, é por isso que eles não se importam com o teste de unidade.
Por fim, o TDD é uma coisa nova: quando eu era garoto, nunca testávamos e escrevíamos um código que funcionava. O teste de unidade faz com que algumas pessoas se sintam acolhedoras e confusas, mas não é absolutamente um requisito para o código correto.
PS. Vejo outra de suas perguntas em que você critica camadas de abstração e aqui critica a falta de construtores de DI! Decida-se :)
fonte
Como tudo muda tão rapidamente quanto você diz, explique a eles que ele será usado para o teste de regressão. O que poupará muitas dores de cabeça quando novos bugs forem introduzidos porque alguém quebrou uma linha de código que foi escrita há 10 anos para resolver um problema que ocorre 1 em cada 10.000.000 execuções de uma função específica que é chamada apenas se o relógio do sistema estiver ligado o cliente tem uma diferença superior a 3 minutos em relação ao relógio do sistema do servidor. Basta perguntar a eles quantos clientes eles podem perder por causa do software de buggy.
fonte
Saliente que encontrar um bug durante o desenvolvimento custa X, durante o teste de 10X e após a implantação de 100X. Veja se eles permitem ao menos realizar um teste piloto em que você implementa o TDD em um módulo específico e, em seguida, faça comparações com outros módulos à medida que são desenvolvidos, testados, implementados e suportados. Dados adequados, você deve demonstrar como foi usado menos esforço para produzir código no módulo TDD. Boa sorte.
fonte
Sim, manter os testes é um fardo. Atualizando-os, atualizando seus dados de teste: tudo isso suga seu tempo.
A alternativa - testar manualmente as coisas, refixar os bugs que regridem, não ser capaz de dizer em segundos que seu código funciona - custa muito mais.
fonte
Bem teste é um fardo, mas é um bom fardo para carregar. É melhor trabalhar com antecedência, o que economizaria uma boa quantidade de tempo quando houver algum problema de produção ou durante a migração. Eu sempre vou querer fazer o teste, mesmo que seja pouco peso, mas quero carregá-lo.
fonte