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.

Exibir ComentáriosOcultar Comentários

2 Comments

  • Heitor
    Posted 06/14/2016 at 17:36 0Likes

    100% de cobertura de testes —> não existe

  • Guilherme Baptista
    Posted 07/04/2016 at 13:21 0Likes

    Oi Heitor, como vai?

    Sei que parece difícil, mas existe. Se considerarmos 100% de cobertura como ter um arquivo de testes para cada arquivo da sua aplicação, não só é possível como acredito estar se tornando comum. Com um time de profissionais adeptos e comprometidos com esse objetivo, conseguimos atingir este nível de cobertura. Mas, isso não garante uma cobertura real de 100% do nosso código, pois podemos deixar de testar algum cenário, deixar algum método passar, etc. Para isso existem ferramentas que analisam a nossa cobertura de testes, como por exemplo o RCov (https://github.com/relevance/rcov). E, indo ainda além, mesmo com uma cobertura 100%, ainda existe a possibilidade de deixarmos passar algo. É aí que entram técnicas mais avançadas como por exemplo “testes de mutação”, que realizam diversas manipulações em seu código durante a execução dos testes para identificar fraquezas, um exemplo de ferramenta assim é o mutant (https://github.com/mbj/mutant).

    Então, ouso ir além, dizendo que 100% de cobertura existe sim e, não só existe, como estamos um passo acima. Já conseguimos atingir 100% de cobertura, o que buscamos agora é aumentar cada vez mais a qualidade e robustez desta cobertura. ;)

Comments are closed.