ti-enxame.com

Existem áreas onde o TDD fornece um alto ROI e outras áreas onde o ROI é tão baixo que não vale a pena acompanhar?

Desenvolvimento orientado a testes. Eu entendo, gosto disso.

Mas escrever testes exige sobrecarga. Portanto, o TDD deve ser usado universalmente em toda a base do código, ou há áreas onde o TDD fornece um alto ROI e outras áreas onde o ROI é tão baixo que não vale a pena acompanhar.

32
Phillip Ngan

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 é refatorado internamente com mais frequência, mas é uma droga ter que consertar seus testes toda vez que uma interface altamente volátil muda drasticamente.

Os aplicativos nos quais tenho trabalhado recentemente são webapps orientados a 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 foi muito bem testada. Os apresentadores são testados apenas nas áreas mais estáveis ​​e a GUI, que muda de hora em hora, quase não tem testes.

27
Fishtoaster

Eu sugiro escrever um conjunto de testes completo em áreas onde seja sensato e prático de fazer. Em áreas menos práticas, faça verificações de sanidade.

Em minha experiência, a sobrecarga de um conjunto completo de casos de teste certamente vale a pena na maioria dos casos, mas realisticamente a cobertura de código tem retornos decrescentes. Em algum ponto, 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 IU pode não ser prático ou mesmo viável. Muitos testes provavelmente dependerão do que o usuário vê e não podem ser automatizados. Como você testaria se um método para gerar um captcha produz uma imagem que pode ser lida por um humano, por exemplo?

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

Meu conselho geral é que você deve 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 irão testar a área em um nível mais alto, em vez de testá-la totalmente.

No exemplo anterior do captcha, talvez escreva testes que verificam se uma imagem do tamanho e formato corretos é retornada e se nenhuma exceção é lançada. Isso dá a você algum nível de segurança sem exagerar.

7
Damovisa

Para mim, o TDD não é uma sobrecarga. É apenas a maneira como escrevo código. Por que você diz que o teste de redação é "sobrecarga"? É apenas parte do processo. Meu ponto de vista é que depuração é uma sobrecarga, e essa é uma atividade que essencialmente parei de fazer quando comecei o TDD-ing. Antes do TDD, a depuração era parte integrante do meu processo de escrita de software.

Acho que desistir da depuração para escrever um teste é um bom negócio.

6
xpmatteo

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

Já que você está testando uma função que retorna uma string html gorda, você está preso fazendo uma análise de html apenas para ver se as coisas funcionaram. Além disso, pode se tornar um pesadelo de sustentabilidade. Um dia você move uma caixa de seleção ao redor e kaboom, seu teste está quebrado.

Gosto de TDD em muitos dos meus testes, mas não é a única ferramenta no cinto dos programadores.

3
Sam Saffron