Qual a diferença entre BDD e TDD?

em Metodologias Ágeis.

BDD e TDD são siglas muito parecidas e constantemente utilizadas no mercado, é muito comum existir uma confusão sobre o significado de cada uma. Para saber diferenciar, basta entender a ideia por trás de cada uma delas:

BDD: Behavior Driven Development

Desenvolvimento Guiado por Comportamento

Aqui temos o conceito de criar códigos baseados em descrições do comportamento que uma funcionalidade deve ter.

Uma forma de descrever uma nova demanda ao desenvolvedor poderia ser:

“Novo sistema de pontuação: Agora os usuários terão uma pontuação em seu perfil, precisamos adicionar um campo chamado “score” ao banco de dados e conseguir adicionar ou remover pontos dos usuários através de uma Stored Procedure.”

Passamos uma informação técnica informando exatamente o que deve ser feito. Já com BDD, a ideia é descrever o comportamento esperado desta funcionalidade e não tentar dizer como ela deve ser implementada:

“Novo sistema de pontuação:

Todo usuário deverá possuir uma pontuação numérica em seu perfil.
Vamos supor que um usuário possui 5 pontos.
Quando receber 10 pontos, ele deverá ter 15 pontos em seu perfil.
Se após isso ele perder 2 pontos, ele terá então 13 pontos em seu perfil.”

Ambas as demandas pretendem atingir o mesmo objetivo: Criar um novo sistema de pontuação, mas na segunda opção, seguindo os conceitos de BDD, temos a descrição de como a funcionalidade deve se comportar ao invés de dizer o que deve ser feito tecnicamente.

Temos de cara duas grandes vantagens:

>>> Primeira: Deixamos o desenvolvedor entender do ponto de vista do usuário o que é esperado da funcionalidade, dando liberdade para ele pensar na melhor solução técnica ao invés de sugerir uma implementação que pode não ser a ideal ou não resultar no comportamento esperado.

>>> Segunda: Pessoas que não são da área técnica podem participar e contribuir ativamente na descrição das demandas, já que não é preciso entender detalhes de programação, mas sim o comportamento esperado do ponto de vista de outras áreas como negócio, marketing, usabilidade, experiência do usuário, etc.

Tudo isso ajuda a integrar as diferentes áreas de uma equipe, diminuir falhas de comunicação e um possível desperdício desenvolvendo algo que não foi exatamente o que imaginavam.

Então, o que queremos é evitar dizer o que deve ser feito a nível de programação. Queremos descrições humanas, contando pequenas estórias sobre o comportamento de uma funcionalidade e se basear nisso para iniciar o processo de desenvolvimento.

Com as demandas geradas em estórias, com descrições humanas sobre o comportamento esperado, aí podemos partir para um ponto de vista mais técnico sobre BDD que envolve questões sobre como criar testes automatizados que validem o código desenvolvido baseados nessas estórias, etc. Mas não vamos nos aprofundar nisso hoje.

TDD: Test Driven Development

Desenvolvimento Guiado por Testes

TDD é uma metodologia de desenvolvimento de software muito simples de entender. A ideia é basicamente: Escrever um teste automatizado antes de começar a desenvolver o código de fato.

Temos então um processo para desenvolver todo e qualquer código:

  1. Escreva um teste para a funcionalidade desejada, sem nada implementado.
  2. Rode o teste criado e veja-o quebrando.
  3. Escreva o código que fará o teste passar.
  4. Rode novamente o teste e veja-o passando.
  5. Revise o código feito, refatorando-o, melhorando o que for possível.
  6. Repita tudo novamente.

A grande vantagem deste processo é garantir uma cobertura de testes para 100% do código, já que nada é desenvolvido sem que um teste exista antes.

Além disso, ajuda o desenvolvedor a pensar melhor sobre as implementações, em como testar e garantir que algo realmente irá funcionar, a revisar o trabalho recém feito para torná-lo ainda melhor e assim por diante.

Conclusão

BDD trabalha para definir como uma demanda chega ao desenvolvedor, integrar diferentes áreas da empresa e pensar a partir do ponto de vista do comportamento esperado de uma funcionalidade pelo usuário. Por consequência, ele acaba influenciando em como os testes são planejados e escritos.

Já o TDD busca garantir a qualidade do código, sempre pensando em 100% de cobertura de testes, melhorar o que acabou de ser feito e nunca escrever uma linha de código sem antes pensar em como garantir que aquilo irá funcionar.

Podemos dizer então que BDD não vai contra o TDD, você pode aplicar ambos os métodos em conjunto ou apenas um deles. Ambos buscam melhorar o desenvolvimento de software e são ideias muito bacanas para se ter em qualquer empresa/projeto.

Você também pode gostar