Existem áreas em que o TDD fornece um ROI alto e outras em que o ROI é tão baixo que não vale a pena segui-lo? [fechadas]

Desenvolvimento orientado a testes. Eu entendo, gosto.

Mas escrever testes exige sobrecarga. Portanto, o TDD deve ser usado universalmente em toda a base de códigos, ou existem áreas em que o TDD fornece um alto ROI e outras áreas em que o ROI é tão baixo que não vale a pena segui-lo.

Eu diria que evite TDD em lugares onde o código provavelmente mudará muito estruturalmente. Ou seja, é ótimo ter uma pilha de testes para um método cuja assinatura muda raramente, mas é refatorada internamente com mais frequência, mas é uma pena ter que corrigir seus testes sempre que uma interface altamente volátil mudar drasticamente.

Os aplicativos em que trabalhei recentemente foram aplicativos da Web baseados em dados, construídos em uma arquitetura baseada em Gui-> Presenter-> BusinessLogic-> Data Access Layer. Minha camada de acesso a dados é testada como ninguém. A camada de lógica de negócios é muito bem testada. Os apresentadores são testados apenas nas áreas mais estáveis, e a GUI, que está mudando a cada hora, quase não tem testes.

Sugiro escrever um conjunto completo de testes em áreas onde é sensato e prático. Em áreas menos práticas, escreva verificações de sanidade.

Na minha experiência, a sobrecarga de um conjunto completo de casos de teste certamente vale a pena na maioria dos casos, mas a cobertura de código realisticamente tem retornos decrescentes. Em algum momento, escrever mais testes apenas para aumentar a cobertura do código simplesmente não faz sentido.

Por exemplo, dependendo do seu idioma / tecnologia, testar a interface do usuário pode não ser prático ou mesmo viável. Muitos testes provavelmente dependerão do que o usuário vê e não pode ser automatizado. Como você testaria se um método para gerar um captcha produz uma imagem legível por um ser humano, por exemplo?

Se um conjunto completo de testes levar três dias para você escrever, a probabilidade de um bug ser introduzido nesse componente no caminho é muito baixa e a função em si leva apenas meia hora para ser escrita, você provavelmente deve pensar muito sobre se esse tempo vale a pena. Talvez apenas escrever uma verificação básica de sanidade para essa função forneça valor?

Meu conselho geral seria que você deveria testar os componentes completamente, onde os testes podem ser escritos com relativa facilidade. No entanto, se for uma área muito difícil de testar, desenhe uma linha na areia e escreva testes que testarão a área em um nível mais alto, em vez de testá-la completamente.

No exemplo captcha anterior, talvez escreva testes que verifiquem se uma imagem do tamanho e formato corretos é retornada e que nenhuma exceção é lançada. Isso oferece um certo nível de garantia sem exagerar.

Para mim, o TDD não está sobrecarregado. É assim que escrevo código. Por que você diz que o teste de escrita é "indireto"? É apenas parte do processo. Meu ponto de vista é que a depuração é sobrecarga, e essa é uma atividade que basicamente parei de fazer quando iniciei o TDD-ing. Antes do TDD, a depuração era parte integrante do meu processo de gravação de software.

Eu acho que desistir da depuração para escrever um teste é uma pechincha muito boa.

Um lugar em que o TDD é realmente péssimo é ao testar visualizações em um aplicativo MVC.

Como você está testando uma função que retorna uma string html gorda, você fica preso na análise de html apenas para verificar se as coisas deram certo. Além disso, pode se tornar um pesadelo de manutenção. Um dia você move uma caixa de seleção e o kaboom, seu teste está quebrado.

Eu gosto de TDD para muitos dos meus testes, mas não é a única ferramenta na faixa de programadores.