As pessoas dizem que "falar sobre TDD dificilmente funciona, se você quiser convencer alguém a TDD, mostre-lhes resultados". No entanto, já estou obtendo ótimos resultados sem o TDD. Mostrando que as pessoas que usam TDD obtêm bons resultados não serão convincentes, quero ver que as pessoas que escrevem TDD e não TDD obtêm melhores resultados com TDD.
Apesar de tudo isso, estou interessado em experimentar o TDD. No entanto, não estou convencido de que vou ganhar algo com isso. Se isso for útil, tentarei empurrá-lo para o resto da minha equipe.
Minha principal pergunta é a seguinte: o TDD serviria a algum propósito de código, se eu já puder provar a correção do código?
Obviamente, nenhum deles é uma bala de prata. Sua prova pode estar errada porque você perdeu um detalhe e seu teste pode falhar em detectar um bug que você não testou. No final, somos humanos, ninguém pode criar um código 100% livre de bugs para sempre. Só podemos nos esforçar para chegar o mais perto possível.
No entanto, o TDD realmente economizaria algum tempo em código que tivesse sua correção comprovada? código que, na máquina de estados em que o código opera, todos os possíveis estados válidos e seus intervalos são reconhecidos pelo desenvolvedor, todos são contabilizados e o código é projetado em uma verificação de erro no estilo de lista de permissões que passa todas as exceções para um manipulador superior para garantir que nada de vazamento inesperado -> sem exibir uma mensagem relevante (dentro do motivo) para o cliente e enviar notificações de log para um administrador.
Respostas com exemplos da vida real seriam melhores.
Alguns esclarecimentos:
Esta questão não é sobre se você pode provar a correção do código ou não. Vamos supor, por padrão, que nem todo código possa ser provado correto dentro de um prazo razoável, mas que algumas partes do código podem ser. Por exemplo, é muito fácil comprovar a correção de um módulo FizzBuzz. Não é muito fácil para um serviço de sincronização de dados baseado em nuvem.
Dentro desse limite, a pergunta é a seguinte: Comece com a suposição de que uma base de código é dividida em 2 partes: [I] partes que foram provadas corretas [II] partes que não foram provadas corretas, mas testadas manualmente para funcionar.
Quero aplicar as práticas de TDD a essa base de código que não as possuía até agora. A pergunta é a seguinte: o TDD deve ser aplicado a todos os módulos, ou seria suficiente aplicá-los apenas aos módulos que não se mostraram corretos?
"Comprovado correto" significa que você pode considerar este módulo completamente funcional, ou seja, ele não depende de nenhum estado global ou externo fora de si mesmo, e possui sua própria API de E / S que outros módulos que interagem com ele devem seguir . Não é possível "quebrar este módulo" alterando o código fora do módulo; na pior das hipóteses, você pode usá-lo incorretamente e receber mensagens de erro formatadas.
Obviamente, todas as regras têm exceções; os erros do compilador nas novas versões do compilador podem introduzir erros neste módulo, mas os mesmos erros podem ser introduzidos nos testes que a testaram e resultam em uma falsa sensação de segurança nos testes que não funcionam mais como planejado. A conclusão é que os testes não são uma solução mágica, eles são outra camada de proteção, e esta pergunta discute a questão de saber se essa camada de proteção vale o esforço no caso específico de um módulo que foi provado correto (suponha que foi de fato).