O Behavior-Driven Development, também conhecido como BDD, é uma metodologia que envolve uma série de práticas que apoiam times para entregas de qualidade e de forma mais ágil, sempre com foco no comportamento que o Software deve possuir. O objetivo principal do BDD é auxiliar e melhorar a comunicação do time, e desta forma permitir construir features com valor real para o negócio.

Além disso, o BDD auxilia a garantir que essas features sejam muito bem planejadas e implementadas. A principal forma para alcançar esses resultados (e que o BDD provê) é encorajar os analistas de negócio, desenvolvedores e QAs a trabalharem mais próximos, com maior interação e compartilhamento de ideias e entendimentos.

A ideia do BDD surgiu a partir dos desafios que Dan North enfrentava com a prática do TDD. Ele começou a perceber que, na maioria das vezes, os desenvolvedores escreviam nomes de testes que não eram nem um pouco claros e não demonstravam o que realmente o teste deveria fazer, e, por conta disso, outras pessoas da equipe e às vezes até mesmo quem escreveu os testes, não conseguia entender sobre o que aquilo se tratava.

Foi quando ele percebeu que o simples fato de mudar o nome do método para algo mais completo e focado no comportamento e acrescentando somente a palavra ‘should’, fez toda a diferença, tornando o teste mais fácil de manter por ter um objetivo mais claro. Com isso, Dan North passou a usar a palavra comportamento ao invés de teste.

Desenvolvimento Tradicional X BDD

No desenvolvimento tradicional, temos um analista de negócio que escreve o requisito que foi coletado com o cliente a respeito de uma nova funcionalidade. Em seguida, esse documento é disponibilizado para que os desenvolvedores leiam e compreendam o que precisa ser desenvolvido. Da mesma forma os QAs estudam o documento e, a partir dos requisitos especificados, eles então iniciam a escrita do plano de teste.

Como podemos perceber, nesse cenário há inúmeras oportunidades de que a informação seja mal compreendida ou até mesmo perdida, pois o analista passa a informação para o desenvolvedor que pode entender uma coisa. Então ele passa a informação pro QA, que pode entender outra coisa, atrapalhando totalmente a comunicação.

Além disso, era comum que nesse processo tradicional de desenvolvimento ocorressem entregas extremamente longas e demoradas.

O que o BDD propõe, é que assim que o analista de negócio entende o que precisa ser implementado, que ele se reúna com o desenvolvedor e o QA para discutirem sobre a funcionalidade proposta. Durante essa conversa, os participantes levantam questionamentos a respeito da história através de exemplos concretos de uso, e através desses exemplos o time decide se a história está ou não pronta para desenvolvimento.

Esses exemplos servem de base para os critérios de aceite que os desenvolvedores utilizarão para determinar se a história está finalizada. Da mesma forma, o time de qualidade também utiliza os exemplos como apoio para elaboração do plano de teste.

O principal objetivo com essa proposta é colocar a equipe envolvida na mesma página, ou seja, com o mesmo entendimento do que precisa ser feito. Com isso o BDD proporciona uma colaboração mais próxima entre toda a equipe, além de reduzir a perda de informações e utilizar exemplos reais como base da documentação.

BDD X TDD

Test-Driven Development é uma técnica de desenvolvimento em que o teste de unidade é escrito antes da funcionalidade. No primeiro momento o teste irá falhar, obviamente porque a funcionalidade a ser testada ainda não está implementada. O passo seguinte é trabalhar na implementação da funcionalidade até que o teste passe.

Por fim há a refatoração, momento em que o código é melhorado. Aqui é onde os padrões de desenvolvimento entram em cena: os códigos duplicados devem ser removidos, variáveis são renomeadas, métodos são extraídos e assim por diante.

Como resultado, teremos um código limpo e fácil para manter; e algo muito importante: o teste deve continuar passando. Feito isso, um novo ciclo se inicia.

A grande vantagem nessa abordagem é que o código é melhor projetado, garante a qualidade desde o início através de testes, evita implementações desnecessárias, fica mais enxuto e, consequentemente, mais fácil de manter.

Fonte: https://cucumber.io/blog/bdd/intro-to-bdd-and-tdd/

O BDD funciona de maneira mais ampla, de forma que este encapsula o TDD. Enquanto o TDD está focado na fase de desenvolvimento, o BDD é aplicado de ponta a ponta no processo de construção do software, abrangendo todas as fases. Está presente desde a fase de concepção e planejamento com os analistas de negócios até o apoio ao time de qualidade, auxiliando a melhorar a comunicação entre a equipe e provendo uma documentação que facilita a elaboração dos critérios de aceite / regras de negócio e que podem se tornar especificações executáveis para a automação dos critérios de aceite.

Assim como mostra a imagem a seguir:

A Reunião dos Três amigos e o mapeamento de Exemplos

“Ignorance is the single greatest impediment to throughput” - Dan North

Como já foi comentado, o BDD melhora a comunicação entre os times, e uma das principais práticas do BDD é a conhecida reunião dos três amigos, que deve ser integrada pelo analista de negócio, um QA e um desenvolvedor. Não necessariamente precisa ter apenas 3 participantes, o importante é não ter muitos de modo que possa comprometer o foco da reunião.

Na reunião dos três amigos, os participantes cooperam para um entendimento mútuo da história, onde cada um desempenha um papel fundamental.

O analista de negócio tem o papel de requisitar o que precisa ser feito, o desenvolvedor faz sugestões de ideias sobre como resolver problemas, enquanto o QA faz protestos, procura por suposições ocultas, e identifica cenários e situações ainda não conhecidas.

Essa reunião proporciona o desafio de suposições, ou seja, evita que as pessoas assumam coisas sem ter certeza, clarifica o entendimento, facilita a descoberta de coisas desconhecidas, além de destacar maus entendimentos.

Uma técnica que pode ser utilizada durante a reunião é o mapeamento de exemplos. Essa prática inicia com a definição da história, em seguida os participantes cooperam para identificar as regras e levantam seus exemplos de forma que a regra de negócio seja colocada em prática.

As dúvidas também fazem parte do jogo, então para cada pergunta não respondida durante a reunião, um card é criado para o registro.

Por fim, devemos ter um quadro como a seguinte:

‍

Gherkin

E então, chegamos ao famigerado Gherkin, que muitas vezes é confundido com o BDD. Por isso, apenas para lembrar, a maneira como escrevemos os cenários não é BDD, então não dizemos que o BDD já foi escrito, OK? ;)

O Gherkin é uma linguagem natural que pode ser compreendida desde o time de negócio até o time técnico e segue a conhecida estrutura Dado, Quando e Então. Essa é a grande vantagem: com o Gherkin criamos uma documentação que será usada e compreendida por todos, tanto pessoas quanto máquinas, e quando integrado com algum framework (como o Cucumber, por exemplo), podemos aplicar a automatização.

Uma vez que estamos satisfeitos com o entendimento adquirido do requisito, a automação é quando a borracha encontra a estrada e os exemplos se tornam especificações executáveis.

Algumas vantagens ao utilizar o BDD

Redução de desperdício através do alinhamento sobre o que precisa ser feito, sempre focando em features que estão alinhadas com o objetivo de negócio, além do curto tempo para feedback.

‍Redução de custos diretamente ligada ao item anterior, principalmente pelo alto nível de qualidade que o BDD proporciona e diminuição de retrabalho.

‍Mudanças mais fáceis e seguras através de um entendimento correto da aplicação por todos e como resultado um código bem escrito, e documentação de fácil entendimento.

‍Releases mais rápidas com uso da automatização dos critérios de aceite, pois os testadores não precisam gastar muito tempo com testes manuais de aceitação.

Contudo, o BDD pode impor alguns desafios quando as partes interessadas não se engajam e não conseguem participar das conversas, quando o time vive em silos ou não está organizado em um contexto ágil, e até mesmo quando a documentação escrita em Gherkin, que deve orientar todo o time, não estiver escrita de forma fiel ao objetivo do negócio.

Conclusão

Como John Ferguson coloca em seu livro ‘BDD in Action’: o BDD é baseado em alguns simples princípios:

• Descrever comportamentos, não especificar soluções;
• Descobrir o comportamento que vai entregar um real valor de negócio;
• Usar conversas e exemplos para explorar o que um sistema deveria fazer.

Como pudemos ver, o BDD está ligado a todo o processo de desenvolvimento, com o objetivo de facilitar a comunicação através de conversas estratégicas, além de oferecer práticas que proporcionam um melhor entendimento das funcionalidades em questão. Com foco no comportamento, o BDD está diretamente ligado a geração de valor, tudo que é pensado e discutido deve atender a um bem maior que é criar uma funcionalidade que gerará um resultado imprescindível ao produto e seus usuários.