Desmistificando o TDD e o BDD

A partir de várias discussões com amigos da comunidade de desenvolvimento sobre boas práticas de TDD/BDD, alguns treinamentos relacionados e lições aprendidas colhidas, resolvi deixar meus 2 centavos sobre o assunto juntamente das referências sobre as polêmicas que venho trazer por meio desta postagem.

Começando com as duas fatídicas perguntas, uma máxima que ouço com muita frequência e uma triste realidade:

“Já fez o TDD?” — Referindo-se a testes de unidade
“TDD vs BDD? Qual é o melhor e quando usar cada um deles?” — Ser humano perdido
“Você só pode usar o BDD para testes de tela, não serve para outro tipo de testes.” — Maximus Decimus Meridius
“Faço os testes unitários depois, porque aí tenho o que testar. Não vejo sentido fazer os testes primeiro.” — Desenvolvedor que não quis ser identificado

Vamos às minhas explicações e considerações:

De volta ao básico

O Desenvolvimento Orientado a Testes (TDD) é uma técnica de desenvolvimento de software multiplicadora do seguinte workflow:

  • Escrever os “testes”;
  • Fazê-los falhar;
  • Implementar nosso código;
  • Fazer os testes passarem;
  • Refatorar;
  • Volte para o primeiro passo.

Defina “testes”

A técnica descreve “teste” como toda e qualquer expectativa tida sobre um código-fonte. Vezes, expressamos essas expectivas por meio de testes unitários, mas não impede que possamos especificar usando testes de integração ou testes de tela, por exemplo.

Por que temos que falhar os testes?

Porque é só uma especificação, não implementamos nada ainda. É como o roteiro de uma palestra ou show. Descrevemos para tomar nota do que esperar da apresentação final e não nos perdermos durante a implementação do “show”.

Testes de integração? Testes de tela? Testes de unidade?

A técnica não impede que definamos essas espectativas por meio de testes de integração ou testes de tela, por exemplo. Mas é sempre bom ter em mente que cada um desses possui objetivos e focos diferentes. Nada impede também o uso conjunto deles, até encorajo.

Pesquisando um pouco, vemos que existem muitos outros tipos de testes.

E o BDD?

Dan North, um importante coach do mundo agile, descobriu que as pessoas passaram a entender melhor os princípios do TDD quando ele parou de usar a palavra “teste”. Ele passou a substituir isso por “cenários”, “comportamentos”, “exemplos”, resultando na compreensão mais rápida dos princípios do desenvolvimento orientado a testes.

Num caso pessoal meu, comentando sobre testes de unidade, vejo muito a justificativa de escrever os testes após o desenvolvimento ser mais natural, pois escrever primeiro sem ter o que testar não faria sentido. Parando para analisar numa perspectiva “testicentrista”, esse raciocínio faz todo sentido e é perfeitamente natural, o que acaba causando toda a confusão conceitual acerca do TDD.

Aslak Hellesøy, em seu livro sobre o Cucumber, diz que o Desenvolvimento Orientado a Comportamentos (BDD) é nada mais nada menos que uma formalização das das melhores técnicas descritas no Desenvolvimento Orientado a Testes (TDD) feita por bons praticantes.

Basicamente, o BDD é uma tentativa dos usuários bem sucedidos de TDD de re-explicar o conceito de Desenvolvimento Orientado a Testes (TDD), incrementando suas próprias experiências ao longo de quase uma década de uso.

Refatoração

Após implementar seu código de acordo com os padrões de arquitetura escolhidos e assegurar-se de que as expectativas (testes) estão passando, o passo seguinte é a refatoração. Na minha humilde opinião, esse é o objetivo da coisa toda.

Como assim?

Na minha compreensão, todo esse workflow tem o objetivo de garantir a refatoração do nosso código com tranquilidade, checando sempre se as expectativas estão batendo. Porque, inicialmente, além do nosso código ser mais verboso, a qualidade dele é geralmente duvidosa. Não devemos postergar esse passo para dar andamento à construção de novas expectativas.

“Os custos de correção de defeitos e refatorações após a implantação são 10x maiores que na fase de construção e 100x maiores que na fase de design.” (Barry W. Boehm: Software Process Management)

Esta prática pode ser comparada à uma monografia escrita para conclusão de curso — quando refatorada durante toda a produção, o custo nas correções aplicadas ao texto é menor, e a qualidade terá um padrão elevado. Diferente de quando as correções acumulam-se, de modo que tudo será corrigido no final. Independente da escolha, a refatoração será sempre necessária para manter a qualidade da monografia, porém, a quantidade de esforço e os resultados serão distintos para os dois casos.

Fontes: