BDD: O que é o Desenvolvimento Orientado por Comportamento

O Desenvolvimento Orientado por Comportamento (BDD, Behavior-Driven Development) é uma metodologia ágil que especifica o software pelo comportamento esperado, em cenários Dado-Quando-Então de linguagem natural. Criado por Dan North em 2006, o BDD alinha negócio, desenvolvimento e qualidade nos mesmos requisitos.

• O que é BDD (Desenvolvimento Orientado por Comportamento)?
• Como funciona um cenário BDD na prática?
• Qual a diferença entre BDD e TDD?
• Por que o BDD melhora a comunicação da equipe?
• Frameworks BDD: Cucumber, JBehave e Spock
• Quais as vantagens e os limites do BDD?

O que é BDD (Desenvolvimento Orientado por Comportamento)?

O BDD é uma técnica de desenvolvimento ágil baseada em ciclos curtos: a equipe descreve o comportamento esperado de uma funcionalidade em cenários concretos, transforma esses cenários em testes automatizados e só então escreve o código que os faz passar. O software nasce validado contra as necessidades do cliente, e não contra suposições técnicas.

A abordagem foi formalizada por Dan North no artigo "Introducing BDD", publicado na revista Better Software em março de 2006. North vinha ensinando TDD (Test-Driven Development, desenvolvimento orientado a testes) e percebia sempre as mesmas dúvidas: por onde começar, o que testar, o que não testar e como nomear os testes. A resposta dele foi trocar o vocabulário: em vez de "testes", falar de "comportamentos".

Nas palavras do próprio North: "I found the shift from thinking in tests to thinking in behaviour so profound that I started to refer to TDD as BDD" — achei a mudança de pensar em testes para pensar em comportamento tão profunda que passei a me referir ao TDD como BDD.

Na prática, o BDD foca no comportamento observável dos objetos e do sistema, não nos detalhes internos de implementação. Analistas de negócio raramente detalham aspectos técnicos, como armazenamento em banco de dados; eles descrevem o que o sistema deve fazer pelo usuário. O BDD captura exatamente essa descrição e a torna executável.

Como funciona um cenário BDD na prática?

Um cenário BDD estrutura qualquer requisito em três blocos: Given (Dado) define o contexto inicial, When (Quando) descreve o evento ou a ação, e Then (Então) indica o resultado esperado. Essa estrutura é padronizada pela sintaxe Gherkin, que segundo a documentação oficial do Cucumber já foi traduzida para mais de 70 idiomas — incluindo o português, com as palavras-chave Dado, Quando e Então.

Um exemplo em português:

Funcionalidade: Saque no caixa eletrônico
  Cenário: Saque com saldo suficiente
    Dado que o cliente tem saldo de R$ 500
    Quando ele solicita um saque de R$ 200
    Então o caixa entrega R$ 200
    E o saldo passa a ser R$ 300

Cada linha do cenário é ligada a um passo de automação (step definition) escrito pelo desenvolvedor. O mesmo texto que o analista de negócio valida com o cliente roda como teste automatizado na esteira de CI/CD, acusando qualquer regressão de comportamento. É por isso que cenários BDD funcionam como documentação viva: se o texto e o sistema divergem, o teste falha.

Qual a diferença entre BDD e TDD?

O BDD não substitui o TDD — ele o aprimora. O TDD, popularizado por Kent Beck com o livro "Test-Driven Development: By Example" (2002), orienta o desenvolvedor a escrever o teste unitário antes do código funcional. O BDD parte do mesmo princípio, mas muda o nível da conversa: em vez de unidades técnicas, especifica comportamentos do sistema em linguagem que o negócio entende.

Na rotina de uma equipe madura, as duas práticas convivem: o BDD define os cenários de aceitação de fora para dentro, e o TDD guia o design das unidades internas — muitas vezes com apoio de objetos mock para isolar dependências nos testes. Quem quiser revisar a base conceitual pode começar pelo nosso guia sobre a importância dos testes de software.

Por que o BDD melhora a comunicação da equipe?

O BDD melhora a comunicação porque obriga negócio, desenvolvimento e qualidade a descrever o sistema com o mesmo vocabulário: a chamada linguagem ubíqua. Essa linguagem é estruturada em torno do modelo de domínio e extraída das histórias e especificações fornecidas pelo cliente durante o levantamento de requisitos — cada termo do cenário corresponde a um conceito real do negócio.

Antes do BDD, o TDD sozinho deixava lacunas de comunicação: desenvolvedores escreviam testes unitários que a equipe de qualidade não lia, enquanto QA (Quality Assurance) validava o comportamento do sistema por outros caminhos. Com cenários Dado-Quando-Então, todos leem e revisam o mesmo artefato, e o desenvolvedor entende por que cada trecho de código deve existir antes de escrevê-lo.

Aslak Hellesøy, criador do Cucumber, resumiu esse espírito em um artigo de 2014 no blog oficial do Cucumber: "If you think Cucumber is a testing tool, please read on, because you are wrong" — se você acha que o Cucumber é uma ferramenta de teste, você está errado. Para Hellesøy, o Cucumber é antes de tudo uma ferramenta de colaboração, que cria entendimento comum entre papéis diferentes do time; os testes de regressão são um subproduto dessa colaboração.

Frameworks BDD: Cucumber, JBehave e Spock

O ecossistema BDD é dominado por frameworks que executam cenários escritos em linguagem natural. O mais conhecido é o Cucumber, com implementações para Java, JavaScript, Ruby e outras linguagens. O crescimento foi rápido: no mesmo artigo de 2014, Hellesøy registrou que o Cucumber alcançou 1 milhão de downloads nos três primeiros anos e 5 milhões de downloads três anos depois.

Na comunidade Java, destacam-se ainda o JBehave, criado pelo próprio Dan North como primeira ferramenta BDD, e o Spock, que usa Groovy para escrever especificações expressivas com blocos given/when/then nativos. A escolha entre eles depende da linguagem do projeto e do quanto o time de negócio participará da escrita dos cenários — se você ainda está se situando nesse vocabulário, veja o que são frameworks e como escolher o ideal.

Quais as vantagens e os limites do BDD?

O BDD entrega quatro vantagens principais, todas derivadas de especificar comportamento antes de implementar:

1. Código de melhor qualidade, porque cada funcionalidade nasce com critério de aceitação explícito.
2. Alta coesão e redução de bugs, já que o comportamento esperado é validado continuamente.
3. Manutenção mais barata e vida útil maior, pois os cenários documentam o sistema de forma sempre atualizada.
4. Testes que refletem o comportamento desejado pelo usuário, e não apenas a estrutura interna do código.

Há, porém, limites claros. Cenários em Gherkin exigem manutenção constante: quando o negócio não participa da escrita, eles viram apenas uma camada extra de sintaxe sobre testes comuns, com custo sem benefício. O BDD também não elimina a necessidade de outras estratégias de verificação, como testes unitários, de integração e exploratórios. A regra prática: adote BDD onde a conversa com o negócio é o gargalo, não onde o desafio é puramente técnico.

Conclusão

O BDD continua sendo, duas décadas depois do artigo de Dan North, a forma mais eficaz de transformar requisitos de negócio em especificações executáveis — mas só entrega valor quando o time trata os cenários como ferramenta de colaboração, e não como burocracia de teste. Se a sua equipe sofre com requisitos mal interpretados e retrabalho, comece pequeno: escolha uma funcionalidade crítica, escreva três cenários Dado-Quando-Então com o negócio na mesa e automatize-os. Aqui no CodeCrush, essa é a nossa recomendação padrão para times que querem elevar a qualidade sem inflar o processo.