O que é BDD (Behavior-Driven Development)?

Dan North desenvolveu BDD ao explorar formas de melhorar o entendimento e a prática de TDD. Seu artigo Introducing BDD foi publicado originalmente na revista Better Software em março de 2006.

A abordagem passou a ser associada a colaboração sobre exemplos e especificações executáveis. Ferramentas como Cucumber apoiam parte desse trabalho, mas instalar uma ferramenta ou adotar Gherkin não estabelece, sozinho, uma prática de BDD.

BDD começa pela conversa sobre o comportamento que importa. Pessoas com perspectivas de negócio, construção e verificação examinam uma necessidade, exploram regras e procuram exemplos que tornem a expectativa concreta. Não é obrigatório que essas perspectivas correspondam a três cargos ou exatamente três participantes.

Uma frase como permitir reservas pode esconder perguntas importantes: quem pode reservar, qual capacidade está disponível, quando a reserva é confirmada e o que acontece se duas solicitações disputam a última vaga? Os exemplos ajudam a descobrir essas diferenças antes de elas se tornarem interpretações divergentes no código.

Descobrir: explore regras, exemplos e dúvidas. O objetivo não é escrever todos os casos possíveis de uma vez. Procure situações que esclareçam decisões relevantes, inclusive limites e exceções. Uma dúvida sem resposta deve continuar visível, em vez de ser preenchida por suposição.

Formular: registre os exemplos numa linguagem que as pessoas envolvidas consigam discutir. O formato Dado, Quando e Então organiza contexto, ação e resultado observável. Gherkin oferece uma sintaxe para esse tipo de descrição, mas a qualidade depende do entendimento do domínio e da escolha dos exemplos.

Verificar: quando fizer sentido, conecte cenários a verificações automatizadas. A automação executa ações e confere resultados por meio de código de apoio. O arquivo de texto não testa o sistema sozinho, e um cenário aprovado não demonstra que todos os comportamentos do produto estão corretos.

Prefira descrever intenção e resultado a detalhar cada clique. Um cenário que menciona nomes de botões e posições de tela pode ficar frágil diante de mudanças visuais que não alteram a regra. Quando a interface em si é o comportamento investigado, seus detalhes podem ser relevantes; a escolha depende da pergunta que o exemplo responde.

Os cenários precisam continuar compreensíveis para o negócio. Se a escrita vira uma linguagem técnica cheia de detalhes de banco e infraestrutura, a participação de outras perspectivas diminui. Separe o comportamento que se quer verificar da implementação necessária para executá-lo.

BDD se relaciona a critérios de aceitação, mas não obriga todos os critérios a usar a mesma forma. A Definition of Done trata de padrões de qualidade do Incremento e é o verbete responsável por essa comparação. Um conjunto de cenários específicos não substitui o padrão geral de pronto.

Também é importante distinguir BDD de uma tradução tardia de testes existentes. Se ninguém conversa sobre exemplos antes de construir, escrever Dado, Quando e Então depois pode documentar o que já foi feito sem esclarecer o que deveria ter sido feito. O ganho depende de influenciar decisões enquanto ainda existe espaço para aprender.

Imagine um serviço com capacidade de 10 participantes por turma. A solicitação inicial diz apenas que o usuário deve conseguir reservar uma vaga. Durante a conversa, negócio, desenvolvimento e testes identificam duas regras: a reserva confirmada ocupa uma vaga e não pode ultrapassar a capacidade.

O grupo formula um primeiro exemplo hipotético:

```gherkin Cenário: Confirmar reserva quando existe vaga Dado que uma turma possui 10 vagas E que 9 reservas estão confirmadas Quando uma pessoa solicita uma reserva válida Então sua reserva é confirmada E a turma fica com 10 reservas confirmadas ```

Um segundo exemplo esclarece o limite:

```gherkin Cenário: Recusar reserva quando a turma está completa Dado que uma turma possui 10 vagas E que 10 reservas estão confirmadas Quando outra pessoa solicita uma reserva Então nenhuma nova reserva é confirmada E a pessoa recebe a informação de que não há vagas ```

Antes, havia uma frase aberta a diferentes interpretações. Depois, existem 2 exemplos verificáveis e uma pergunta nova: o que deve acontecer quando duas solicitações chegam ao mesmo tempo para a última vaga? O time não presume que os dois cenários cobrem concorrência. Registra a questão e combina o comportamento esperado antes de implementar essa parte.

Os exemplos também não definem uma política de lista de espera, cancelamento ou validade da solicitação. Se essas regras forem necessárias, precisam ser discutidas. Esse limite evita transformar uma demonstração simples em uma especificação aparentemente completa de todo o serviço.

Cursos K21 recomendados