Desenvolvimento dirigido por Testes (Test Driven Development - TDD) é uma das práticas centrais do eXtreme Programming (XP) (embora algumas ideias centrais tenham tido origem décadas antes do XP) e é considerado por muitos um dos fatores chave para a entrega de software de alta qualidade desenvolvido utilizando métodos ágeis.
Recentemente, David Heinemeier Hansson (DHH), autor do Ruby on Rails e fundador do Basecamp fez o discurso de abertura do Railsconf 2014 (vídeo disponível no link) no qual ele Ele deu sequência à discussão com dois artigos em seu blog:"TDD está Morto - Vida Longa aos Testes" e "Dano de Design Induzido por Testes", no qual se aprofunda no assunto.
Brian Oken resumiu os pontos citados pelo DHH nas conversas e nos artigos da seguinte forma:
- Muitos desenvolvedores que promovem o TDD fazem você pensar que o seu código é sujo se você não está fazendo TDD;
- Definir o seu design a partir de testes unitários não se trata de uma boa ideia;
- A noção do TDD de que "testes devem ser rápidos" é ilusão;
- A confiança puramente no TDD pode fazer com que os testes do sistema sejam completamente esquecidos;
- O foco somente nos testes unitários não ajuda a produzir um sistema incrível.
- Cobertura de 100% de testes é uma ilusão;
- Programadores querem que o software seja uma ciência, mas não é. Ele está mais para um processo criativo de escrever;
- Software bom não é como engenharia;
- É como escrever. Um texto limpo e conciso é melhor do que um texto complexo;
- Ter Clareza é bom. Boa clareza deveria ser a meta principal e não cobertura ou velocidade de execução de testes;
- Se tornar um bom desenvolvedor é tão difícil quanto se tornar um bom escritor;
- Assim como escrever, a forma de se tornar um bom desenvolvedor é escrevendo muito código, lendo muito código, sempre buscando clareza.
Tem sido extensa a reação da comunidade (veja os tweets com a hashtag #tddisdead), com reações que variam deste "é claro" até o oposto desta visão: "isso é muito estúpido".
Muitas dessas respostas têm como foco a necessidade de aplicar o TDD de forma pragmática.
Uncle Bob Martin diz em uma resposta que: "Se você não está fazendo TDD ou algo tão efetivo quanto TDD, então você deveria se sentir mal". Ele continua:
Por que nós fazemos TDD? Nós fazemos TDD por um motivo principal e vários outros secundários, entre eles:
- Nós perdemos menos tempo em processo de debug.
- Os testes funcionam como uma documentação exata, precisa e não ambígua em um nível mais baixo do sistema.
- Escrever os testes primeiro requer desacoplamento, algo que as outras estratégias de teste não requerem; e nós acreditamos que tal desacoplamento é benéfico.
Esses são benefícios secundários do TDD e todos são discutíveis. Existe, porém, um benefício que, dadas certas condições, não existe discussão:
- Se você confia tanto em um conjunto de testes a ponto de colocar seu software em produção com base nos resultados destes, e se esses testes podem ser executados em segundos ou minutos, então você pode modificar sem medo seu código de forma rápida e fácil.
Martin Fowler organizou de uma série de videoconferências entre DHH, Kent Beck (cuja resposta inicial pode ser encontrada aqui) e ele mesmo, para explorar o uso do TDD e seus impactos no design de software.
No total foram cinco videoconferências, sendo a última uma sessão de perguntas e respostas do público.
Fowler resumiu as conversas assim:
- Nós falamos sobre a nossa experiência variada com o fluxo de TDD e a maneira na qual TDD e código auto-testável são frequentemente confundidos.
- David sente que fazer TDD leva a abordagens tais como o Rails Hexagonal que é um dano de design induzido pelos testes porque gera complexidade excessiva devido à indireção. Kent pensa que isso tem menos a ver com TDD e mais com a qualidade das decisões de design.
- Nós discutimos a várias formas de obter feedback enquanto programamos e o papel da QA na melhoria desses feedbacks para o desenvolvedor.
- Nós discutimos algumas desvantagens de testar e do TDD, tais como: fazer testes demais ou equipes que dão mais valor para os testes do que para o código funcional.
Gergely Brautigam disse na publicação "TDD está morto - Não realmente" em seu blog:
TDD não está morto. com tantos que o adotam, como ele poderia estar morto? É como perguntar se Design Patterns estão mortos, automação funcional está morta ou as bolachas Oreo estão mortas.
Não, não está morto e nem será morto. Ele talvez mude para algo novo, talvez algo melhor, mas nunca será morto. Então, vamos pular essa parte.
Ele continua falando sobre a importância de fazer diferentes tipos de testes e os motivos mais comuns para os testes não serem bem feitos em muitas equipes de software. Ele cita a falta de interesse pela qualidade como uma perspectiva comum e a pressão de tempo, que faz com que muitos desenvolvedores não escrevam testes da mesma forma que escrevem código. Ele conclui:
É minha opinião pessoal, experiência e observação em um período de 10 anos de teste de software. Iniciando com um esqueleto frágil e alguns testes no começo já ajudarão em longo prazo. Escrevendo ao menos um ou dois testes de aceitação já ajudarão a entender melhor a lógica de negócio. Eu não estou falando para escrever um conjunto completo de testes, eu posso entender que você não quer fazer isso, mas pela qualidade, escreva ao menos um par.
Gil Zilberfeld fez um comentário em seu blog que complementa o conselho do Manifesto Ágil:
"Nós estamos descobrindo formas melhores de desenvolver software, desenvolvendo e ajudando os outros a desenvolver"
Nós ainda não terminados de descobrir estas formas. TDD é um item que encontramos em nossa jornada, podem existem outros.