TDD e BDD são sinônimos

A Busca pelo Software Ideal

Em desenvolvimento de software, TDD e BDD são frequentemente debatidos como abordagens distintas, cada uma com sua própria filosofia e terminologia. No entanto, a origem de ambas é a mesma.

Este artigo explora um “mundo” onde TDD e BDD são estratégias colaborativas para construir software de qualidade, independentemente das palavras-chave utilizadas ou das ferramentas adotadas.

TDD e BDD são sinônimos, assim como Dado/Quando/Então e Arrange/Act/Assert também são

Sempre pensei isso, mas foi bom confirmar lendo o livro Clean Craftsmanship – Disciplines, Standards, and Ethics, de Robert C. Martin.

No capítulo 3, onde o autor explica Test-Driven Development Advanced (TDD Avançado), há um sub-capítulo sobre BDD (Behavior-Driven Development).

Neste capítulo, o autor cita.

Também deve ficar claro que o teste TDD e o teste BDD são sinônimos.

Interpreto a citação acima da seguinte forma. “TDD e BDD são técnicas para ajudar desenvolvedores e desenvolvedoras de software a garantir que o software certo está sendo construído, não só que o software está sendo construído certo.”

Se você chama isso de TDD, ATDD, BDD, ou seja lá o que for, não importa. O que importa é que o software certo seja construído.

Outra frase que me chamou atenção durante a leitura foi a seguinte.

Mesmo que as instruções Dado/Quando/Então nunca sejam executadas como testes, elas são valiosas como especificações de comportamento.

Se você me conhece, sabe que não uso tais instruções (Dado/Quando/Então) em meus testes automatizados e também não recomendo.

Se não me conhece, agora está sabendo.

Falo mais sobre isso neste vídeo.

No entanto, não considero ruim que tal especificação exista. Pelo contrário. Especificações bem feitas ajudam a entendermos se estamos construindo o software certo.

Só não precisamos complicar a vida do time de desenvolvimento com abstrações desnecessárias.

Times de desenvolvimento software precisam ser ágeis, e para isso, os testes tem que falar a língua deles (ex.: Java, JavaScript, Ruby, Python, C++, C#, etc.)

E quando você dá liberdade aos profissioanais que desenvolvem para testarem o software que estão construindo, e lhes ajuda a entender o que precisa ser construído, você foca em fazê-los/las entender o problema que precisa ser resolvido e eles/elas o resolvem para você.

Ou seja, não imponha como o problema deve ser resolvido, em vez disso, foque em explicar da melhor forma possível QUAL problema precisa ser resolvido.

No mesmo sub-capítulo, Robert cita Liz Keogh falando sobre BDD, onde ela diz.

É usar exemplos para falar sobre como uma aplicação se comporta… E conversar sobre este exemplos.

Ou seja, na sua essência, BDD, assim como TDD, são, sempre foram e sempre serão sobre colaboração e entendimento, não só especificação executável em forma de testes.

Deixe os testes na linguagem com a qual o time de desenvolvimento se sente confortável. Não force-os a usar Cucumber (ou JBehave e outros) só por que você leu em um livro, ou alguém te disse que “este é o jeito certo de se fazer”.

Em vez disso, descreva exemplos reais e converse sobre estes exemplos com o time de forma que haja uma compreensão compartilhada do que precisa ser construído.

O jeito certo de fazer é fazer de forma que o software certo seja construído, entregue, atualizado, incrementado, melhorado, etc., sem quebrar a cada mudança.

A ferramenta que será usada para testar não deve ser o foco, em vez disso, garanta que os testes certos sejam escritos e executados nas horas certas e que eles sempre estejam verdes, ou seja, passando e dando confiança aos times de que mudanças podem ser entregues em tempo hábil.

Não force ferramentas e metodologias aos seus times, em vez disso, ajude-os a escreverem o software certo, através de conversas com base em exemplos reais.

Walmyr Lima e Silva Filho

Assita uma conversa sobre BDD, com Cristiano Caetano, no Canal TAT no YouTube.

Por fim, o autor cita.

O vocabulário Dado/Quando/Então e Arrange/Act/Assert são obviamente sinônimos. Se você tiver alguma dúvida sobre isso, considere o seguinte:

Dado que os dados de testes sejam “arranjados” (Arranged)

Quando executo a “ação” (Act) em teste

Então o resultado esperado é “afirmado” (Asserted)

Você não precisa das palavras-chave Dado/Quando/Então para organizar seus testes com pré-condições, ações e resultados esperados.

Seu time vai usar este padrão, pois é assim que se escreve testes. Ou seja, todo teste tem uma ou mais pré-condições, uma ou mais ações e uma ou mais verificações de resultados esperados.

Se estes serão escritos com Dado/Quando/Então (ex.: Cucumber), jUnit, Mocha, Jest, Cypress, não é uma decisão da gestão. É uma decisão do time.

Deixe seu time resolver os problemas da forma que acharem conveniente, não force-os a resolvê-los da forma que “você acha que funciona”. Você irá se surpreender.

---

Estes são só pensamentos de um desenvolvedor de software que ama testes automatizados.

Bora escrever o software certo e bons testes!