Experiência negativa do TDD [fechada]

Para adicionar, outra preocupação com o TDD que notei é:

O TDD causa uma mudança inadvertida no foco da equipe de desenvolvimento do Código de Qualidade para as Capas de Teste e a Cobertura de Código! Eu pessoalmente não gostei do TDD, pois ele me torna menos criativo e torna o desenvolvimento de software um processo mecânico chato ! Os testes de unidade são úteis quando usados criteriosamente, mas se tornam um fardo quando tratados com o objetivo de desenvolvimento de software.

Eu conheço um cara que é um gerente e é tecnicamente insípido uma vez obcecado pelo TDD. Era uma coisa tão mágica para ele que ele acreditava que traria soluções mágicas para todos os problemas em seu software mal arquitetado com o código menos sustentável. Para não dizer o que aconteceu com esse projeto, ele falhou miseravelmente em suas mãos, enquanto todas as suas carteiras eram verdes. Eu acho que o TDD o ajudou a obter algum tipo de informação estatística como "99/100 dos meus casos são verdes" etc. e essa foi a razão de sua obsessão, pois ele nunca seria capaz de avaliar a qualidade ou sugerir melhorias no design.

Minha principal experiência negativa é tentar usar o TDD para editar o código de outro programador que não possui testes ou testes de integração muito básicos. Quando vou adicionar um recurso, ou corrigir um problema com o dito código; Eu preferiria escrever um teste primeiro (o modo TDD). Infelizmente, o código está strongmente acoplado e não posso testar nada sem muita refatoração.

A refatoração é um ótimo exercício, mas é necessário para colocar o código em um estado testável. E depois desse passo, não tenho freios e contrapesos para ver se minhas mudanças quebraram alguma coisa; curto de executar o aplicativo e examinar cada caso de uso.

Por outro lado, adicionar recursos / corrigir erros em um projeto TDD se torna muito simples. Por natureza, o código escrito com o TDD é geralmente bastante desacoplado com pequenos pedaços para trabalhar.

Em qualquer caso, o TDD é uma diretriz. Siga-o ao ponto em que você acha que obtém a máxima eficácia. Cobertura de teste decente e código desacoplado, código bem escrito.

Eu fiz a experiência que às vezes confio muito nos meus testes quando se trata do design do sistema. Eu sou basicamente muito baixo em detalhes de implementação para dar o passo atrás para olhar o quadro maior. Isso geralmente resulta em um design desnecessariamente complexo. Eu sei, devo refatorar o código, mas às vezes tenho a impressão de que poderia economizar muito tempo dando um passo atrás com mais frequência.

Dito isto, se você tem um framework como os rails, onde suas decisões arquiteturais são muito limitadas, esses problemas são basicamente inexistentes.

Outro problema é quando você confia em seus testes cegamente. A verdade é - como qualquer outro código - seus testes podem ter erros também. Portanto, seja tão crítico em relação aos seus testes quanto sua implementação.

Como grande fã de TDD, às vezes vejo essas desvantagens

• Tentação de escrever muitos testes em prol de quase 100% de cobertura de código. Na minha opinião, não é necessário escrever testes
  • para getters / setters de propriedade simples
  • para todos os casos em que uma exceção é lançada
  • verifica a mesma funcionalidade por diferentes camadas. (Exemplo: se você tem um teste unitário para verificar a validação de entrada para cada parâmetro, então não é necessário repetir todos esses testes por meio de um teste de integração também)

• Custos de manutenção do código de teste para testes semelhantes, que variam apenas levemente (criados por meio de duplicação de código (também conhecido como copy-paste-inheritance)). Se você já tem um, é fácil criar um similar. Mas, se você não refatorar o código de teste, eliminando a duplicação de código nos métodos auxiliares, poderá precisar de algum tempo para corrigir os testes, caso os detalhes de implementação de seu código de negócios sejam alterados.

• Se você estiver sob pressão de tempo , poderá ficar tentado a eliminar testes quebrados (ou comentá-los) em vez de corrigir eles. Desta forma você perde o investimento nos testes

Ainda não encontrei mais de um cenário como desenvolvedor de jogos em que o TDD valeu a pena. E a instância em que estava, era um código que era puramente matemático por natureza e precisava de uma abordagem sólida para testar um grande número de casos de borda simultaneamente - uma necessidade rara.

Simplicity - "What is the simplest thing that could possibly work?"
The message is very clear. Given the requirements for today, design and write your software. Do not try to anticipate the future, let the future unfold. It will often do this in very unpredictable ways making anticipation a cost that is often too expensive to afford."

Os conceitos de coragem e de apertar feedback , loops que ele menciona também são, em minha opinião, a chave para a produtividade.

Minha experiência negativa no TDD, por mais limitada que seja, é simplesmente saber por onde começar! Por exemplo, tentarei fazer algo TDD e não saberá onde começar a bloquear testes de coisas triviais (posso criar um objeto Foo , posso passar um Quux para o Baz e Testes que não testam nada), ou se eu estou tentando implementá-lo em um projeto existente, então eu acho que eu teria que reescrever várias classes para poder usá-los em TDD. O resultado final é que eu rapidamente abandono completamente a noção.

Provavelmente não ajuda que muitas vezes eu seja a única pessoa em toda a empresa que sabe o que é o teste unitário (TDD ou de outra forma) e porque é uma coisa boa.

Zelotes do TDD.

IMO, a maior mentira deles é que o TDD levará você à salvação a um melhor design de algoritmo. Veja o famoso solucionador Soduku escrito em TDD: aqui , aqui , aqui , aqui e aqui

E compare-o com o solucionador de sudoku de Peter Norvig usando o TDD, mas usando a engenharia antiga: link

Se você usar o TDD a partir desses artigos "fanáticos", você terá a sensação errada de que seu software não apresenta erros.

TDD tem alguns benefícios:

• Você se concentra em como para chamar seu código e o que esperar primeiro (ao escrever o teste primeiro) em vez de se concentrar em resolver o problema e depois colá-lo na aplicação. A modularidade facilita a simulação e o envolvimento.
• Os testes garantem que seu programa funcione da mesma maneira antes e depois de uma refatoração. Isso não significa que seu programa está livre de erros, mas que continua funcionando da mesma maneira.

O TDD é sobre investimento a longo prazo. O esforço é compensado quando você acessa o modo de manutenção de seu aplicativo e, se o aplicativo não for planejado para chegar a esse ponto, talvez você nunca recupere o investimento.

Eu considero o ciclo vermelho-verde de TDD com os passos do bebê semelhantes a uma lista de verificação para um avião. É chato e tedioso verificar cada uma das coisas no avião antes da decolagem, especialmente se for trivialmente simples (os passos de bebê TDD), mas verificou-se que aumenta a segurança. Além de verificar tudo funciona, essencialmente redefine o plano . Em outras palavras, um avião é reinicializado antes de cada decolagem.

Minha experiência negativa sobre o TDD é algo que sinto com muitas coisas novas e sensacionalistas. Na verdade, gosto de TDD porque garante a validade do meu código e, o que é ainda mais importante: posso reconhecer testes com falha, depois de adicionar um novo código ou qualquer tipo de refatoração.

O que me incomoda sobre o TDD é o fato de que há muitas regras ou diretrizes sobre isso. Como ainda é muito novo, a maioria de nós experimenta ser iniciante no TDD. Então, o que funciona bem para alguns de nós, pode não funcionar para os outros. O que eu quero dizer é que não existe uma maneira "certa ou errada" de realizar o TDD: existe o jeito que funciona para mim - e a minha equipe se eu tiver uma.

Portanto, contanto que você escreva testes - antes ou depois do código de produção não importa IMHO - eu não tenho certeza se o teste realmente significa que você tem que seguir todas as diretrizes que são apresentadas agora, já que elas ainda não são provou ser a solução ideal para o trabalho diário. Se você encontrar uma maneira melhor de escrever testes, você deve publicá-la em um blog, discuti-la aqui ou escrever um artigo sobre ela. Assim, em dez anos ou mais, poderíamos ter compartilhado experiência suficiente para saber qual regra do TDD pode ser considerada boa ou não em uma determinada situação.

Eu tenho, em mais de uma ocasião, código escrito que descartei no dia seguinte, já que era desajeitado. Eu reiniciei com o TDD e a solução foi melhor. Então eu não tive muito na linha de experiência negativa do TDD. No entanto, tendo dito isso, passei algum tempo pensando sobre um problema e encontrando uma solução melhor fora do espaço TDD.

Eu descobri que o TDD tem um desempenho ruim quando se trata de sistemas emergentes. Sou desenvolvedor de jogos de vídeo e recentemente usei o TDD para criar um sistema que usa vários comportamentos simples para criar movimentos realistas para uma entidade.

Por exemplo, há comportamentos responsáveis por afastá-lo de áreas perigosas de tipos diferentes e responsáveis por direcioná-lo para áreas interessantes de tipos diferentes. Amalgamação da saída de cada comportamento cria um movimento final.

As entranhas do sistema foram implementadas facilmente, e o TDD foi útil aqui para especificar o que cada subsistema deveria ser responsável.

No entanto, tive problemas ao especificar como os comportamentos interagem e, mais importante, como eles interagem ao longo do tempo. Muitas vezes, não havia resposta certa e, embora meus testes iniciais estivessem passando, o departamento de QA continuava a encontrar casos extremos em que o sistema não funcionava. Para encontrar a solução correta, tive que fazer uma iteração de vários comportamentos diferentes, e se eu atualizasse os testes toda vez para refletir os novos comportamentos antes de verificar que funcionavam no jogo, talvez acabasse jogando os testes uma e outra vez. Então eu deletei esses testes.

Eu deveria ter tido testes mais strongs que capturaram os casos de borda QA descobertos, mas quando você tem um sistema como esse que fica em cima de muitos sistemas de física e jogabilidade, e você está lidando com Com o passar do tempo, torna-se um pesadelo especificar exatamente o que está acontecendo.

Eu quase com certeza cometi erros na minha abordagem, e como eu disse para a coragem do sistema, o TDD funcionou de forma brilhante, e até mesmo apoiou alguns poucos refatoradores otimizadores.