O que é BDD? Desenvolvimento orientado a comportamento

BDD (Desenvolvimento Orientado a Comportamento)

Em inglês: Behavior-Driven Development

Também chamado de: BDD, desenvolvimento guiado por comportamento, desenvolvimento orientado por comportamento

Definição

Prática colaborativa em que negócio, desenvolvimento e teste combinam o comportamento por meio de exemplos concretos, muitas vezes escritos em Gherkin e automatizados.

Behavior-Driven Development (BDD), ou desenvolvimento orientado a comportamento, é uma forma de construir entendimento compartilhado antes de o código ser escrito. Produto, desenvolvimento e teste (muitas vezes chamados de “three amigos”) discutem uma funcionalidade por meio de exemplos concretos de como ela deve se comportar. Esses exemplos viram os critérios de aceitação, e muitos times os automatizam depois como especificações executáveis com ferramentas como Cucumber, Reqnroll (sucessor do SpecFlow) ou Behave.

Exemplo

Uma conversa sobre uma regra de desconto se transforma em exemplos como estes:

Feature: Loyalty discount

  Scenario: Gold members get 10% off orders over 100
    Given a customer with Gold membership
    When they check out a basket worth 120.00
    Then the order total is 108.00

  Scenario: The discount does not apply at exactly 100
    Given a customer with Gold membership
    When they check out a basket worth 100.00
    Then the order total is 100.00

O segundo cenário é o mais valioso. Escrevê-lo obriga a responder “acima de 100, ou a partir de 100?” antes que alguém construa a coisa errada.

As três práticas

Descoberta (Discovery). Explorar a funcionalidade com exemplos, encontrar casos de borda e perguntas em aberto.
Formulação (Formulation). Escrever os exemplos combinados de forma estruturada e legível pelo negócio, geralmente em Gherkin.
Automação (Automation). Ligar cada passo a código para que os exemplos rodem como testes e funcionem como documentação viva.

Erros comuns

Tratar BDD como ferramenta de teste. Escrever Gherkin depois do código, sozinho e sem conversa, traz o custo de uma camada de tradução sem o benefício do entendimento compartilhado.
Passos no nível da UI. “When I click the button with id submit” descreve a interface, não o comportamento. Os passos devem sobreviver a um redesign.
Automatizar todos os cenários pelo navegador. Uma regra de negócio como o desconto acima geralmente é mais rápida e mais confiável de automatizar contra uma API ou a camada de serviço.
Bibliotecas de passos enormes. Centenas de step definitions ligeiramente diferentes são difíceis de manter. Mantenha o vocabulário pequeno e focado no domínio.

O BDD funciona bem quando as pessoas do negócio realmente leem e contribuem com os cenários. Quando ninguém fora da engenharia olha para eles, código de teste simples com bons nomes costuma ser mais prático.