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.