O que é BDD

O desenvolvimento orientado a comportamento (Behavior Driven Development, BDD) é um processo de desenvolvimento de software que nasceu do desenvolvimento orientado a testes (TDD). Ele usa exemplos para ilustrar o comportamento do sistema, escritos numa linguagem que todos os envolvidos entendem, do cliente ao desenvolvedor. ^{[1] [2] [8]}

Dan North, que deu nome e forma ao BDD, o resume assim:

BDD é usar exemplos em vários níveis para criar um entendimento comum e trazer à tona as incertezas, para entregar software que importa.

Dan North ^[2]

Esses exemplos têm dois destinos: viram especificações executáveis e servem como testes de aceitação. O BDD se concentra em:

• oferecer um processo e ferramentas comuns, que aproximam desenvolvedores, analistas de negócio e demais interessados, para entregar software com valor de negócio;
• descrever o que o sistema deve fazer, e não como deve ser implementado;
• dar mais legibilidade e visibilidade ao que está sendo construído;
• verificar não só se o software funciona, mas se atende ao que o cliente espera.

Este tutorial serve tanto para desenvolvedores quanto para analistas de negócio. Ele supõe que você já conhece os fundamentos de testes; se precisar revisá-los, veja o tutorial Testes de software.

Por que o BDD surgiu

O custo de corrigir um defeito se multiplica quando ele não é encontrado no momento certo. E muitos defeitos nascem antes do código: de requisitos mal entendidos. Se o requisito não for capturado corretamente, o erro atravessa projeto, código e testes, fica caro de corrigir e o produto final pode não atender ao cliente. ^[2]

Era preciso uma abordagem que partisse dos requisitos, mantivesse o foco neles durante todo o desenvolvimento e garantisse que fossem cumpridos. O BDD faz isso porque:

• deriva exemplos dos diferentes comportamentos esperados do sistema;
• escreve esses exemplos com os termos do domínio do negócio, para que todos entendam, inclusive o cliente;
• confirma os exemplos com o cliente de tempos em tempos, por meio de conversas;
• mantém o foco nos exemplos durante todo o desenvolvimento;
• usa os exemplos como testes de aceitação.

As duas práticas do BDD

• Especificação por Exemplo (SbE): usa exemplos nas conversas para ilustrar as regras de negócio e o comportamento do software. Assim, product owner, analistas, testadores e desenvolvedores eliminam os mal-entendidos mais comuns sobre os requisitos. ^[6]
• Desenvolvimento orientado a testes (TDD): no contexto do BDD, transforma os exemplos em especificações executáveis e legíveis. Os desenvolvedores as usam como guia para implementar cada pedaço de funcionalidade, o que gera um código enxuto e uma suíte de testes de regressão automatizados que mantém baixo o custo de manutenção. ^[4]

BDD e o Manifesto Ágil

No desenvolvimento ágil, o BDD é a forma de chegar a um entendimento comum sobre o que ainda falta especificar. O product owner descreve os comportamentos que espera; os desenvolvedores detalham as especificações e fazem perguntas; e o comportamento atual do sistema é considerado, para que a nova funcionalidade não quebre as existentes.

O Manifesto Ágil valoriza mais os itens da esquerda do que os da direita, e o BDD se alinha a cada um deles: ^[7]

TDD, a base do BDD

Para entender por que se diz que “o BDD vem do TDD”, é preciso entender o TDD.

O problema do teste no final

Na abordagem tradicional, o teste vem depois de cada etapa (test-last). Na prática, ele acaba sendo espremido ou pulado por atrasos, prazos apertados e pressão para entregar. O teste unitário, que caberia ao desenvolvedor, costuma ser o primeiro a cair, com justificativas como “sou desenvolvedor, não testador” ou “meu código não tem defeitos”. O resultado é qualidade comprometida, responsabilidade concentrada nos testadores, correções caras depois da entrega e clientes insatisfeitos.

Teste primeiro

A abordagem test-first inverte a ordem: em vez de escrever o código e depois testar (de dentro para fora), escreve-se o teste e depois o código (de fora para dentro). Ela aparece na Programação Extrema (XP) e no TDD, formalizado por Kent Beck: o desenvolvedor escreve o teste unitário de um módulo antes de escrever uma única linha dele, e então escreve o código com o objetivo de fazer o teste passar. ^{[4] [5]}

O ciclo Vermelho, Verde, Refatorar

1. escolha o pedaço de código a escrever;
2. escreva um teste para ele;
3. rode o teste: ele falha, porque o código ainda não existe (vermelho);
4. escreva o mínimo de código para o teste passar (verde);
5. rode todos os testes para garantir que continuam passando;
6. refatore: remova duplicações e melhore o código;
7. repita para o próximo pedaço.

Cada volta deve ser curta; uma hora de trabalho costuma ter muitos ciclos.

Vantagens do TDD

• o desenvolvedor precisa entender o resultado esperado, e como testá-lo, antes de codificar;
• um componente só está pronto quando o teste passa e o código foi refatorado;
• como a suíte roda a cada refatoração, o retorno sobre o que ainda funciona é constante;
• os testes unitários servem de documentação sempre atualizada;
• cada defeito encontrado ganha um teste que o reproduz, o que reduz o tempo de depuração e impede que ele volte;
• o desenvolvedor pode mudar o projeto e refatorar com segurança, o que torna o software mais fácil de manter;
• como boa parte do teste acontece durante o desenvolvimento, o teste antes da entrega fica mais curto.

Onde o TDD deixa dúvidas

O ponto de partida são as histórias de usuário, que descrevem comportamento. Com o TDD puro, o desenvolvedor fica com perguntas: quando testar? O que testar? Como saber se uma especificação foi atendida? O código entrega valor de negócio? É aqui que o BDD entra.

Mitos sobre o TDD

ATDD: aceitação primeiro

O desenvolvimento orientado a testes de aceitação (ATDD) define os critérios e os testes de aceitação quando as histórias de usuário são criadas, no início do desenvolvimento. O foco é a comunicação e o entendimento comum entre clientes, desenvolvedores e testadores. ^[9]

As práticas centrais são:

• discutir cenários do mundo real para construir um entendimento comum do domínio;
• usar esses cenários para chegar aos critérios de aceitação;
• automatizar os testes de aceitação;
• concentrar o desenvolvimento em fazer esses testes passarem;
• usar os testes como especificação viva, que facilita as mudanças.

Com isso, os requisitos ficam sem ambiguidade e sem lacunas funcionais, todos passam a enxergar os casos especiais que os desenvolvedores previram, e os testes de aceitação guiam o desenvolvimento.

De TDD para BDD

Dan North percebeu que programadores que praticavam TDD esbarravam sempre nas mesmas dúvidas: por onde começar, o que testar e o que não testar, quanto testar de uma vez, que nome dar aos testes e como entender por que um teste falhou. A resposta dele foi mudar o vocabulário: pensar em comportamento, e não em testes. ^[3]

Achei a mudança de pensar em testes para pensar em comportamento tão profunda que comecei a chamar o TDD de BDD, ou desenvolvimento orientado a comportamento.

Dan North, “Introducing BDD”, 2006 ^[3]

O TDD se preocupa com como algo vai funcionar; o BDD, com por que estamos construindo aquilo. As respostas do BDD às dúvidas do TDD são:

O modelo de história

Como [papel]
Eu quero [funcionalidade]
Para que [benefício]

Ou seja: quando a funcionalidade é executada, quem ganha o benefício é a pessoa no papel.

O modelo de exemplo

Dado um contexto inicial,
Quando um evento acontece,
Então garanta alguns resultados.

Partindo de um contexto, quando um evento acontece, sabemos quais resultados devem ocorrer. Martin Fowler descreve esse formato como uma forma de representar testes a partir da especificação por exemplo. ^[16]

Exemplo: o caixa eletrônico de Dan North

História: O cliente saca dinheiro
  Como cliente,
  Eu quero sacar dinheiro no caixa eletrônico,
  Para que eu não precise enfrentar fila no banco.

Cenário 1: A conta tem saldo
  Dado que a conta tem saldo
  E o cartão é válido
  E o caixa tem dinheiro
  Quando o cliente pede dinheiro
  Então a conta é debitada
  E o dinheiro é entregue
  E o cartão é devolvido

Cenário 2: A conta passou do limite do cheque especial
  Dado que a conta está negativa além do limite
  E o cartão é válido
  Quando o cliente pede dinheiro
  Então uma mensagem de recusa é exibida
  E o dinheiro não é entregue
  E o cartão é devolvido

O evento é o mesmo nos dois cenários, mas o contexto muda, e por isso os resultados são diferentes. ^[3]

TDD × BDD

• O TDD descreve como o software funciona.
• O BDD descreve como o usuário usa o software, promove colaboração e comunicação, dá ênfase a exemplos de comportamento e busca especificações executáveis derivadas desses exemplos.

O ciclo de fora para dentro

O ciclo de desenvolvimento do BDD começa pelo lado de fora, no comportamento que o usuário vê, e desce até as unidades de código. Steve Freeman e Nat Pryce chamam isso de ciclo duplo: um ciclo externo de aceitação envolve vários ciclos internos de TDD. ^[17]

1. escreva um exemplo de alto nível, de valor para o negócio (com Cucumber, por exemplo), que fica vermelho;
2. escreva um exemplo de baixo nível, de unidade, para o primeiro passo da implementação, que também fica vermelho;
3. implemente o mínimo de código para esse exemplo passar: verde;
4. escreva o próximo exemplo de baixo nível que aproxima o passo 1 de passar;
5. repita os passos 3 e 4 até o exemplo de alto nível ficar verde.

O estado vermelho ou verde funciona como uma permissão:

• com os testes de baixo nível verdes, você pode escrever novos exemplos ou refatorar, mas sem acrescentar funcionalidade durante a refatoração;
• com os testes vermelhos, você só pode mexer no código para fazê-los passar. Resista à vontade de adiantar o próximo teste, que ainda não existe, ou de criar funções que o cliente não pediu.

Especificação por Exemplo

Gojko Adzic, autor de Specification by Example, a define como um conjunto de padrões de processo que facilitam mudanças em produtos de software, para garantir que o produto certo seja entregue com eficiência. Em vez de declarações abstratas, os requisitos e os testes funcionais são capturados com exemplos realistas, definidos em colaboração. ^[6]

Ela se apoia numa linguagem ubíqua, conceito de Eric Evans: um vocabulário preciso e compartilhado, criado por uma equipe multidisciplinar e usado por todos, nos requisitos, no código e nos testes. ^[12] Os exemplos servem de entrada direta para testes automatizados que refletem o domínio do negócio, e por isso a SbE cuida ao mesmo tempo de construir o produto certo e de construí-lo do jeito certo.

Por que exemplos

Exemplos são mais fáceis de entender e mais difíceis de interpretar errado. Viram requisitos executáveis, que podem ser testados sem tradução e ficam registrados numa documentação viva. O foco passa a ser prevenir defeitos, e não apenas detectá-los.

Vantagens: mais qualidade, menos desperdício, menos risco de defeitos em produção, esforço mais focado, mudanças mais seguras e maior envolvimento do negócio.

Quando usar: funciona bem em negócios ou organizações complexas, inclusive em sistemas legados. Funciona mal em problemas puramente técnicos e em produtos centrados na interface gráfica.

Exemplos como testes de aceitação

• uma mesma ilustração serve de requisito detalhado e de teste;
• o progresso do projeto é medido em comportamentos: cada teste verifica um comportamento, e um teste que passa significa que aquele comportamento está pronto. Se o projeto precisa de 100 comportamentos e 60 passam, ele está 60% concluído;
• os testadores deixam de só achar defeitos e passam a preveni-los, participando do desenho da solução;
• a automação mostra na hora o impacto de uma mudança de requisito.

Os seis padrões de processo

1. Especificar em colaboração: os Três Amigos

O objetivo é que os diferentes papéis tenham um entendimento e um vocabulário comuns, que todos contribuam com a sua perspectiva e que a responsabilidade pelas funcionalidades seja compartilhada. Isso acontece numa oficina de especificação conhecida como reunião dos Três Amigos: negócio (analista ou PO), desenvolvimento e teste. ^[10]

Na reunião, o negócio apresenta os requisitos e os testes da nova funcionalidade; os três discutem e revisam as especificações; desenvolvimento e teste apontam o que falta. Todos usam a linguagem do domínio (mantendo um glossário, se preciso), procuram diferenças e conflitos, evitam detalhes de implementação e chegam a um consenso sobre se a funcionalidade está suficientemente especificada. O mapeamento de exemplos ajuda a dar forma à conversa, com cartões para a história, as regras, os exemplos e as perguntas em aberto. ^[11]

2. Ilustrar com exemplos

Dado <uma pré-condição>
E <outras pré-condições>        # opcional
Quando <uma ação ou gatilho ocorre>
Então <uma pós-condição>
E <outras pós-condições>       # opcional

Cada exemplo descreve um comportamento do sistema e é também um critério de aceitação. A equipe discute os exemplos até concordar que cobrem o comportamento esperado.

3. Refinar a especificação

• seja preciso; se um exemplo ficar complexo, divida-o;
• use a perspectiva do negócio e evite detalhes técnicos;
• considere condições positivas e negativas, valores-limite e casos extremos;
• mantenha o vocabulário do domínio;
• discuta os exemplos com o cliente e fique só com os que interessam a ele, sem tentar cobrir todas as combinações;
• especifique regras de negócio adicionais, como cálculos complexos e transformações de dados;
• inclua cenários não funcionais, como desempenho e usabilidade, quando fizer sentido.

4. Automatizar os exemplos

A camada de automação deve ser bem fina: apenas ligar a especificação ao sistema em teste. Foque na especificação, e não no script; mostre com clareza a relação entre entradas e saídas.

5. Validar com frequência

Inclua a validação dos exemplos no pipeline, a cada mudança. Os princípios são testar cedo, testar bem e testar sempre. Um comportamento só está pronto quando o teste correspondente passa.

6. Documentação viva

Mantenha as especificações curtas e simples, organize-as, evolua-as com o trabalho e deixe-as acessíveis a todo o time. Como elas rodam como testes, nunca ficam desatualizadas sem que alguém perceba.

Antipadrões

Antipadrões são práticas recorrentes que parecem razoáveis, mas causam problemas. Na Especificação por Exemplo, os mais comuns são: ^[6]

Para evitá-los, reúna-se para especificar com exemplos, limpe e melhore os exemplos, escreva o código que os satisfaz, automatize-os e repita a cada história. Na prática, isso significa:

• Colaborar: negócio, desenvolvimento e teste contribuem com as suas perspectivas; o processo vale mais do que os próprios testes.
• Focar no “o quê”: não tente cobrir todos os casos, mantenha os exemplos simples e compreensíveis para os usuários e deixe as ferramentas fora das oficinas.
• Focar no negócio: escreva as especificações no nível da intenção de negócio, envolva o negócio na criação e na revisão e esconda os detalhes na camada de automação.
• Estar preparado: os benefícios não aparecem de imediato, a adoção é desafiadora e exige tempo e investimento, e a automação tem custo.

Gherkin

Gherkin é a linguagem usada para escrever funcionalidades, cenários e passos. O objetivo é escrever requisitos concretos. Compare: ^[13]

• “Clientes devem ser impedidos de informar dados de cartão inválidos.”
• “Se o cliente informar um número de cartão que não tem exatamente 16 dígitos, ao enviar o formulário ele deve ser exibido de novo, com uma mensagem informando o número correto de dígitos.”

A segunda frase não tem ambiguidade, evita erros e pode ser testada. O Gherkin tem versões em dezenas de idiomas, inclusive o português; basta indicar o idioma na primeira linha. ^[14]

Palavras-chave

Arquivos Gherkin são texto simples com extensão .feature. Toda linha não vazia começa com uma palavra-chave:

Funcionalidade

Tem a palavra-chave, um nome na mesma linha e uma descrição opcional (mas recomendada) nas linhas seguintes. Por convenção, o arquivo leva o nome da funcionalidade em minúsculas, com sublinhados: saque_no_caixa_eletronico.feature. Para identificar funcionalidades, pode-se usar o modelo de injeção de funcionalidade: Para <atingir um objetivo>, como <tipo de usuário>, eu quero <uma funcionalidade>.

Cenário

Uma funcionalidade costuma ter de 5 a 20 cenários. Cada um descreve um contexto (Dado), uma ação (Quando) e um resultado esperado (Então); E e Mas acrescentam passos do mesmo tipo:

Cenário: Tentativa de saque com cartão roubado
  Dado que tenho R$ 100 na conta
  Mas o meu cartão é inválido
  Quando peço R$ 50
  Então o cartão não deve ser devolvido
  E devo ser orientado a procurar o banco

Cada cenário deve fazer sentido e rodar sozinho, sem depender de outro ter rodado antes. Isso torna os testes mais simples, permite rodar só uma parte deles e, dependendo do sistema, rodá-los em paralelo.

Esquema do cenário

Quando vários cenários só mudam os valores, use um esquema: os marcadores ficam entre < e > e os valores vêm na tabela de exemplos, em que cada linha vira um cenário.

# language: pt
Funcionalidade: Somar
  Esquema do Cenário: Somar dois números
    Dado a entrada "<entrada>"
    Quando a calculadora é executada
    Então a saída deve ser "<saida>"

    Exemplos:
      | entrada | saida |
      | 2+2     | 4     |
      | 98+1    | 99    |
      | 255+390 | 645   |

Cucumber e as definições de passos

O Cucumber é uma ferramenta livre de linha de comando que lê arquivos .feature e executa os cenários contra o sistema. Ele junta, num só lugar, a especificação executável, o teste automatizado e a documentação viva. ^[15]

Um teste de aceitação típico em Cucumber mostra a hierarquia: testes de aceitação se referem a funcionalidades, as funcionalidades são explicadas por cenários e os cenários são feitos de passos.

# language: pt
Funcionalidade: Cadastro
  O cadastro deve ser rápido e simpático.

  Cenário: Cadastro bem-sucedido
    Novos usuários devem receber um e-mail de confirmação
    e ser cumprimentados pelo nome.

    Dado que escolhi me cadastrar
    Quando me cadastro com dados válidos
    Então devo receber um e-mail de confirmação
    E devo ver uma mensagem de boas-vindas personalizada

Como funciona

• cada passo em Gherkin precisa de uma definição de passo: um trecho de código com uma expressão associada;
• ao executar um passo, o Cucumber procura a definição cuja expressão casa com o texto e roda o código dela. A palavra-chave (Dado, Quando, Então) não entra na comparação;
• parâmetros como {int} ou {string} capturam valores do texto e os passam para o código;
• se todos os passos rodam sem erro, o cenário passa; ao final, o Cucumber informa quantos cenários passaram e o que falhou.

O Cucumber tem implementações para várias plataformas, como Java (Cucumber-JVM), JavaScript (Cucumber.js) e Ruby, e se integra a ferramentas como Selenium e Spring.

Ferramentas

Um equívoco comum é achar que BDD é uma ferramenta. BDD é uma abordagem de desenvolvimento; as ferramentas apenas ajudam. Há até equipes que praticam Especificação por Exemplo sem ferramenta nenhuma. As mais conhecidas:

SpecFlow e Reqnroll

O SpecFlow foi por anos a ferramenta de BDD do .NET: usava Gherkin, gerava uma classe de teste por funcionalidade e um método por cenário, transformava tags em categorias de teste e esquemas de cenário em testes por linha. A Tricentis aposentou o SpecFlow, e o Reqnroll nasceu como uma retomada de código aberto do projeto, compatível com ele e com migração simples. ^[18]

Behave

No Behave, para Python, os arquivos ficam numa pasta features: os arquivos .feature com os cenários, uma pasta steps com as definições de passos em Python e, opcionalmente, um arquivo de ambiente com código para rodar antes e depois de passos, cenários ou funcionalidades. ^[19]

Concordion

O Concordion, para Java, automatiza a Especificação por Exemplo com especificações escritas em linguagem natural, com parágrafos e tabelas, sem exigir o formato Dado/Quando/Então. ^[20]

Revisão rápida

Tente responder antes de abrir cada pergunta.

Referências

1. Giovani Perotto Mesquita, “Behavior Driven Development Tutorial”, GitHub Gist, texto original deste tutorial, gist.github.com/GiovaniPM/d115d35e2d4c0fe4062f8b6f98c84d82.
2. Tutorialspoint, “Behavior Driven Development Tutorial”, acesso em 25/09/2026, tutorialspoint.com/behavior_driven_development.
3. Dan North, “Introducing BDD”, 2006, dannorth.net/introducing-bdd.
4. Kent Beck, Test-Driven Development: By Example, Addison-Wesley, 2002.
5. Martin Fowler, “Test Driven Development”, martinfowler.com/bliki/TestDrivenDevelopment.html.
6. Gojko Adzic, Specification by Example, Manning, 2011, gojko.net/books/specification-by-example.
7. Manifesto para o Desenvolvimento Ágil de Software, 2001, agilemanifesto.org/iso/ptbr/manifesto.html.
8. Agile Alliance, “Behavior Driven Development (BDD)”, glossário, agilealliance.org/glossary/bdd.
9. Agile Alliance, “Acceptance Test Driven Development (ATDD)”, glossário, agilealliance.org/glossary/atdd.
10. Agile Alliance, “Three Amigos”, glossário, agilealliance.org/glossary/three-amigos.
11. Matt Wynne, “Introducing Example Mapping”, blog do Cucumber, cucumber.io/blog/bdd/example-mapping-introduction.
12. Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, 2003.
13. Cucumber, “Gherkin Reference”, acesso em 25/09/2026, cucumber.io/docs/gherkin/reference.
14. Cucumber, “Localisation” (idiomas do Gherkin), acesso em 25/09/2026, cucumber.io/docs/gherkin/languages.
15. Cucumber, “Step Definitions”, acesso em 25/09/2026, cucumber.io/docs/cucumber/step-definitions.
16. Martin Fowler, “GivenWhenThen”, martinfowler.com/bliki/GivenWhenThen.html.
17. Steve Freeman e Nat Pryce, Growing Object-Oriented Software, Guided by Tests, Addison-Wesley, 2009.
18. Reqnroll, site oficial, acesso em 25/09/2026, reqnroll.net.
19. Behave, documentação, acesso em 25/09/2026, behave.readthedocs.io.
20. Outras ferramentas: Concordion, concordion.org; JBehave, jbehave.org; Behat, docs.behat.org.

What BDD is

Behavior-driven development (BDD) is a software development process that grew out of test-driven development (TDD). It uses examples to illustrate how the system behaves, written in a language everyone involved understands, from the client to the developer. ^{[1] [2] [8]}

Dan North, who named and shaped BDD, sums it up like this:

BDD is using examples at multiple levels to create a shared understanding and surface uncertainty to deliver software that matters.

Dan North ^[2]

These examples have two uses: they become executable specifications and they serve as acceptance tests. BDD focuses on:

• providing a shared process and shared tools that bring developers, business analysts and other stakeholders together to deliver software with business value;
• describing what the system should do, not how it should be implemented;
• making what is being built more readable and visible;
• checking not only that the software works, but that it meets what the client expects.

This tutorial is for developers and business analysts alike. It assumes you already know the basics of testing; if you need a refresher, see the Software testing tutorial.

Why BDD came about

The cost of fixing a defect multiplies when it is not found at the right time. And many defects are born before the code: from misunderstood requirements. If a requirement is not captured correctly, the error travels through design, code and tests, becomes expensive to fix, and the final product may not meet the client’s needs. ^[2]

What was needed was an approach that starts from the requirements, keeps the focus on them throughout development and makes sure they are met. BDD does this because it:

• derives examples of the system’s different expected behaviors;
• writes those examples in the terms of the business domain, so that everyone understands them, including the client;
• confirms the examples with the client from time to time, through conversations;
• keeps the focus on the examples throughout development;
• uses the examples as acceptance tests.

The two practices of BDD

• Specification by Example (SbE): uses examples in conversations to illustrate the business rules and the behavior of the software. Product owners, analysts, testers and developers thereby remove the most common misunderstandings about the requirements. ^[6]
• Test-driven development (TDD): in the context of BDD, it turns the examples into readable, executable specifications. Developers use them as a guide to implement each piece of functionality, which produces lean code and a suite of automated regression tests that keeps maintenance costs low. ^[4]

BDD and the Agile Manifesto

In agile development, BDD is the way to reach a shared understanding of what is still to be specified. The product owner describes the behaviors they expect; developers flesh out the specifications and ask questions; and the system’s current behavior is taken into account, so the new feature does not break existing ones.

The Agile Manifesto values the items on the left more than those on the right, and BDD aligns with each of them: ^[7]

TDD, the foundation of BDD

To understand why people say that “BDD comes from TDD”, you need to understand TDD.

The problem with testing last

In the traditional approach, testing comes after each stage (test-last). In practice, it gets squeezed or skipped because of delays, tight deadlines and pressure to deliver. Unit testing, which belongs to the developer, is usually the first to go, with excuses such as “I’m a developer, not a tester” or “my code has no defects”. The result is compromised quality, responsibility concentrated on testers, expensive fixes after delivery and unhappy clients.

Test first

The test-first approach flips the order: instead of writing code and then testing it (inside-out), you write the test and then the code (outside-in). It appears in Extreme Programming (XP) and in TDD, formalized by Kent Beck: the developer writes the unit test for a module before writing a single line of it, then writes the code with the goal of making the test pass. ^{[4] [5]}

The Red, Green, Refactor cycle

1. pick the piece of code to write;
2. write a test for it;
3. run the test: it fails, because the code does not exist yet (red);
4. write the minimum code to make the test pass (green);
5. run all the tests to make sure they still pass;
6. refactor: remove duplication and improve the code;
7. repeat for the next piece.

Each turn should be short; an hour of work usually contains many cycles.

Advantages of TDD

• the developer must understand the expected result, and how to test it, before coding;
• a component is only done when the test passes and the code has been refactored;
• since the suite runs after every refactoring, feedback on what still works is constant;
• unit tests act as documentation that is always up to date;
• every defect found gets a test that reproduces it, which cuts debugging time and keeps it from coming back;
• the developer can change the design and refactor safely, which makes the software easier to maintain;
• since much of the testing happens during development, testing before delivery is shorter.

Where TDD leaves questions

The starting point is user stories, which describe behavior. With plain TDD, the developer is left with questions: when to test? What to test? How do I know a specification has been met? Does the code deliver business value? This is where BDD comes in.

TDD misconceptions

ATDD: acceptance first

Acceptance test-driven development (ATDD) defines acceptance criteria and acceptance tests when user stories are created, early in development. The focus is on communication and shared understanding among clients, developers and testers. ^[9]

Its key practices are:

• discussing real-world scenarios to build a shared understanding of the domain;
• using those scenarios to arrive at acceptance criteria;
• automating the acceptance tests;
• focusing development on making those tests pass;
• using the tests as a living specification that makes change easier.

As a result, requirements are unambiguous and free of functional gaps, everyone gets to see the special cases developers foresaw, and the acceptance tests guide development.

From TDD to BDD

Dan North noticed that programmers practicing TDD kept running into the same doubts: where to start, what to test and what not to test, how much to test in one go, what to call their tests and how to understand why a test fails. His answer was to change the vocabulary: think in terms of behavior, not tests. ^[3]

I found the shift from thinking in tests to thinking in behaviour so profound that I started to refer to TDD as BDD, or behaviour-driven development.

Dan North, “Introducing BDD”, 2006 ^[3]

TDD is concerned with how something will work; BDD, with why we are building it at all. BDD’s answers to TDD’s doubts are:

The story template

As a [role]
I want [feature]
So that [benefit]

That is: when the feature is executed, the person in the role gets the benefit.

The example template

Given some initial context,
When an event occurs,
Then ensure some outcomes.

Starting from a context, when an event happens, we know what the outcomes should be. Martin Fowler describes this format as a way of representing tests that comes from specification by example. ^[16]

Example: Dan North’s ATM

Story: Customer withdraws cash
  As a customer,
  I want to withdraw cash from an ATM,
  So that I don’t have to wait in line at the bank.

Scenario 1: Account is in credit
  Given the account is in credit
  And the card is valid
  And the dispenser contains cash
  When the customer requests cash
  Then ensure the account is debited
  And ensure cash is dispensed
  And ensure the card is returned

Scenario 2: Account is overdrawn past the overdraft limit
  Given the account is overdrawn
  And the card is valid
  When the customer requests cash
  Then ensure a rejection message is displayed
  And ensure cash is not dispensed
  And ensure the card is returned

The event is the same in both scenarios, but the context differs, so the outcomes differ. ^[3]

TDD × BDD

• TDD describes how the software works.
• BDD describes how the end user uses the software, fosters collaboration and communication, emphasizes examples of behavior and aims at executable specifications derived from those examples.

The outside-in cycle

The BDD development cycle starts on the outside, with the behavior the user sees, and works down to the units of code. Steve Freeman and Nat Pryce call this the double loop: an outer acceptance loop wraps several inner TDD loops. ^[17]

1. write a high-level example of business value (with Cucumber, for instance) that goes red;
2. write a low-level, unit example for the first step of the implementation, which also goes red;
3. implement the minimum code to make that example pass: green;
4. write the next low-level example that moves step 1 closer to passing;
5. repeat steps 3 and 4 until the high-level example goes green.

The red or green state works as a permission:

• with the low-level tests green, you may write new examples or refactor, but without adding functionality while refactoring;
• with the tests red, you may only change code to make them pass. Resist the urge to get ahead of the next test, which does not exist yet, or to build features the client did not ask for.

Specification by Example

Gojko Adzic, author of Specification by Example, defines it as a set of process patterns that facilitate change in software products to ensure that the right product is delivered efficiently. Instead of abstract statements, requirements and functional tests are captured with realistic examples, defined collaboratively. ^[6]

It relies on a ubiquitous language, a concept from Eric Evans: a precise, shared vocabulary, created by a cross-functional team and used by everyone, in requirements, code and tests. ^[12] The examples feed directly into automated tests that reflect the business domain, which is why SbE takes care of building the right product and building it right at the same time.

Why examples

Examples are easier to understand and harder to misinterpret. They become executable requirements that can be tested without translation and are kept in living documentation. The focus shifts to preventing defects, not just detecting them.

Advantages: higher quality, less waste, lower risk of production defects, more focused effort, safer changes and greater business involvement.

When to use it: it works well in complex businesses or organizations, including legacy systems. It works poorly for purely technical problems and for products centered on the graphical interface.

Examples as acceptance tests

• a single illustration serves as both detailed requirement and test;
• project progress is measured in behaviors: each test checks one behavior, and a passing test means that behavior is done. If a project needs 100 behaviors and 60 pass, it is 60% finished;
• testers move from finding defects to preventing them, taking part in the design of the solution;
• automation shows the impact of a requirement change right away.

The six process patterns

1. Specify collaboratively: the Three Amigos

The goal is for the different roles to share understanding and vocabulary, for everyone to contribute their perspective and for ownership of features to be shared. This happens in a specification workshop known as the Three Amigos meeting: business (analyst or PO), development and testing. ^[10]

In the meeting, the business side presents the requirements and tests for the new feature; the three discuss and review the specifications; development and testing point out what is missing. Everyone uses the domain language (keeping a glossary if needed), looks for differences and conflicts, avoids implementation details and reaches consensus on whether the feature is specified well enough. Example mapping helps structure the conversation, with cards for the story, the rules, the examples and the open questions. ^[11]

2. Illustrate with examples

Given <some precondition>
And <additional preconditions>      # optional
When <an action or trigger occurs>
Then <some postcondition>
And <additional postconditions>     # optional

Each example describes one behavior of the system and is also an acceptance criterion. The team discusses the examples until it agrees they cover the expected behavior.

3. Refine the specification

• be precise; if an example gets complex, split it;
• take the business perspective and avoid technical details;
• consider positive and negative conditions, boundary values and edge cases;
• stick to the domain vocabulary;
• discuss the examples with the client and keep only those that matter to them, without trying to cover every combination;
• specify additional business rules, such as complex calculations and data transformations;
• include non-functional scenarios, such as performance and usability, when it makes sense.

4. Automate the examples

The automation layer should be very thin: just wiring the specification to the system under test. Focus on the specification, not the script; show the link between inputs and outputs clearly.

5. Validate frequently

Add example validation to the pipeline, at every change. The principles are test early, test well and test often. A behavior is only done when its test passes.

6. Living documentation

Keep the specifications short and simple, organize them, evolve them with the work and make them accessible to the whole team. Since they run as tests, they never go out of date without someone noticing.

Anti-patterns

Anti-patterns are recurring practices that look reasonable but cause problems. In Specification by Example, the most common are: ^[6]

To avoid them, get together to specify with examples, clean up and improve the examples, write the code that satisfies them, automate them and repeat for every story. In practice, this means:

• Collaborating: business, development and testing contribute their perspectives; the process is worth more than the tests themselves.
• Focusing on the “what”: do not try to cover every case, keep examples simple and understandable to users, and keep tools out of the workshops.
• Focusing on the business: write specifications at the level of business intent, involve the business in creating and reviewing them and hide the details in the automation layer.
• Being prepared: the benefits are not immediate, adoption is challenging and takes time and investment, and automation has a cost.

Gherkin

Gherkin is the language used to write features, scenarios and steps. Its purpose is to write concrete requirements. Compare: ^[13]

• “Customers should be prevented from entering invalid credit card details.”
• “If a customer enters a credit card number that is not exactly 16 digits long, when they try to submit the form, it should be redisplayed with an error message advising them of the correct number of digits.”

The second sentence has no ambiguity, avoids errors and can be tested. Gherkin exists in dozens of languages; you just declare the language on the first line. ^[14]

Keywords

Gherkin files are plain text with the .feature extension. Every non-blank line starts with a keyword:

Feature

It has the keyword, a name on the same line and an optional (but recommended) description on the following lines. By convention, the file is named after the feature in lowercase, with underscores: atm_cash_withdrawal.feature. To identify features, you can use the feature injection template: In order to <meet some goal>, as a <type of user>, I want <a feature>.

Scenario

A feature usually has 5 to 20 scenarios. Each describes a context (Given), an action (When) and an expected outcome (Then); And and But add more steps of the same kind:

Scenario: Attempt withdrawal using stolen card
  Given I have $100 in my account
  But my card is invalid
  When I request $50
  Then my card should not be returned
  And I should be told to contact the bank

Each scenario must make sense and run on its own, without depending on another having run before. This makes tests simpler, lets you run just a subset of them and, depending on the system, run them in parallel.

Scenario outline

When several scenarios differ only in their values, use an outline: placeholders go between < and >, and the values come from the examples table, where each row becomes a scenario.

Feature: Add
  Scenario Outline: Add two numbers
    Given the input "<input>"
    When the calculator is run
    Then the output should be "<output>"

    Examples:
      | input   | output |
      | 2+2     | 4      |
      | 98+1    | 99     |
      | 255+390 | 645    |

Cucumber and step definitions

Cucumber is a free command-line tool that reads .feature files and runs the scenarios against the system. It brings executable specification, automated test and living documentation together in one place. ^[15]

A typical Cucumber acceptance test shows the hierarchy: acceptance tests refer to features, features are explained by scenarios and scenarios are made of steps.

Feature: Sign up
  Sign up should be quick and friendly.

  Scenario: Successful sign up
    New users should get a confirmation email
    and be greeted personally.

    Given I have chosen to sign up
    When I sign up with valid details
    Then I should receive a confirmation email
    And I should see a personalized greeting message

How it works

• each Gherkin step needs a step definition: a piece of code with an expression attached;
• when running a step, Cucumber looks for the definition whose expression matches the text and runs its code. The keyword (Given, When, Then) is not part of the match;
• parameters such as {int} or {string} capture values from the text and pass them to the code;
• if every step runs without error, the scenario passes; at the end, Cucumber reports how many scenarios passed and what failed.

Cucumber has implementations for several platforms, such as Java (Cucumber-JVM), JavaScript (Cucumber.js) and Ruby, and integrates with tools such as Selenium and Spring.

Tools

A common misconception is that BDD is a tool. BDD is a development approach; tools only help. Some teams even practice Specification by Example with no tool at all. The best known:

SpecFlow and Reqnroll

For years, SpecFlow was the BDD tool for .NET: it used Gherkin, generated one test class per feature and one method per scenario, turned tags into test categories and scenario outlines into row-based tests. Tricentis retired SpecFlow, and Reqnroll was created as an open-source reboot of the project, compatible with it and easy to migrate to. ^[18]

Behave

In Behave, for Python, files live in a features folder: the .feature files with the scenarios, a steps folder with the Python step definitions and, optionally, an environment file with code to run before and after steps, scenarios or features. ^[19]

Concordion

Concordion, for Java, automates Specification by Example with specifications written in natural language, with paragraphs and tables, without requiring the Given/When/Then format. ^[20]

Quick review

Try to answer before opening each question.

References

1. Giovani Perotto Mesquita, “Behavior Driven Development Tutorial”, GitHub Gist, original text of this tutorial, gist.github.com/GiovaniPM/d115d35e2d4c0fe4062f8b6f98c84d82.
2. Tutorialspoint, “Behavior Driven Development Tutorial”, accessed 25 September 2026, tutorialspoint.com/behavior_driven_development.
3. Dan North, “Introducing BDD”, 2006, dannorth.net/introducing-bdd.
4. Kent Beck, Test-Driven Development: By Example, Addison-Wesley, 2002.
5. Martin Fowler, “Test Driven Development”, martinfowler.com/bliki/TestDrivenDevelopment.html.
6. Gojko Adzic, Specification by Example, Manning, 2011, gojko.net/books/specification-by-example.
7. Manifesto for Agile Software Development, 2001, agilemanifesto.org.
8. Agile Alliance, “Behavior Driven Development (BDD)”, glossary, agilealliance.org/glossary/bdd.
9. Agile Alliance, “Acceptance Test Driven Development (ATDD)”, glossary, agilealliance.org/glossary/atdd.
10. Agile Alliance, “Three Amigos”, glossary, agilealliance.org/glossary/three-amigos.
11. Matt Wynne, “Introducing Example Mapping”, Cucumber blog, cucumber.io/blog/bdd/example-mapping-introduction.
12. Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, 2003.
13. Cucumber, “Gherkin Reference”, accessed 25 September 2026, cucumber.io/docs/gherkin/reference.
14. Cucumber, “Localisation” (Gherkin languages), accessed 25 September 2026, cucumber.io/docs/gherkin/languages.
15. Cucumber, “Step Definitions”, accessed 25 September 2026, cucumber.io/docs/cucumber/step-definitions.
16. Martin Fowler, “GivenWhenThen”, martinfowler.com/bliki/GivenWhenThen.html.
17. Steve Freeman and Nat Pryce, Growing Object-Oriented Software, Guided by Tests, Addison-Wesley, 2009.
18. Reqnroll, official website, accessed 25 September 2026, reqnroll.net.
19. Behave, documentation, accessed 25 September 2026, behave.readthedocs.io.
20. Other tools: Concordion, concordion.org; JBehave, jbehave.org; Behat, docs.behat.org.

Cos’è il BDD

Lo sviluppo guidato dal comportamento (Behavior Driven Development, BDD) è un processo di sviluppo software nato dallo sviluppo guidato dai test (TDD). Usa degli esempi per illustrare il comportamento del sistema, scritti in un linguaggio che tutti i partecipanti capiscono, dal cliente allo sviluppatore. ^{[1] [2] [8]}

Dan North, che ha dato nome e forma al BDD, lo riassume così:

Il BDD consiste nell’usare esempi a più livelli per creare una comprensione condivisa e far emergere le incertezze, per consegnare software che conta.

Dan North ^[2]

Questi esempi hanno due usi: diventano specifiche eseguibili e fanno da test di accettazione. Il BDD si concentra su:

• offrire un processo e strumenti comuni, che avvicinano sviluppatori, analisti di business e altri interessati, per consegnare software con valore di business;
• descrivere cosa deve fare il sistema, e non come deve essere implementato;
• rendere più leggibile e visibile ciò che si sta costruendo;
• verificare non solo che il software funzioni, ma che soddisfi le aspettative del cliente.

Questo tutorial è utile sia agli sviluppatori sia agli analisti di business. Presuppone che conosca già le basi del test; se ti serve un ripasso, vedi il tutorial Test del software.

Perché è nato il BDD

Il costo per correggere un difetto si moltiplica quando non viene trovato al momento giusto. E molti difetti nascono prima del codice: da requisiti fraintesi. Se un requisito non viene colto correttamente, l’errore attraversa progetto, codice e test, diventa costoso da correggere e il prodotto finale può non soddisfare il cliente. ^[2]

Serviva un approccio che partisse dai requisiti, li tenesse al centro per tutto lo sviluppo e garantisse che fossero rispettati. Il BDD lo fa perché:

• ricava esempi dei diversi comportamenti attesi del sistema;
• scrive questi esempi con i termini del dominio di business, perché tutti li capiscano, cliente compreso;
• conferma gli esempi con il cliente di tanto in tanto, attraverso conversazioni;
• mantiene il focus sugli esempi per tutto lo sviluppo;
• usa gli esempi come test di accettazione.

Le due pratiche del BDD

• Specifica tramite esempi (SbE): usa esempi nelle conversazioni per illustrare le regole di business e il comportamento del software. Così product owner, analisti, tester e sviluppatori eliminano i malintesi più comuni sui requisiti. ^[6]
• Sviluppo guidato dai test (TDD): nel contesto del BDD, trasforma gli esempi in specifiche eseguibili e leggibili. Gli sviluppatori le usano come guida per implementare ogni pezzo di funzionalità, il che produce codice snello e una suite di test di regressione automatizzati che tiene bassi i costi di manutenzione. ^[4]

BDD e Manifesto Agile

Nello sviluppo agile, il BDD è il modo per arrivare a una comprensione comune di ciò che resta da specificare. Il product owner descrive i comportamenti che si aspetta; gli sviluppatori dettagliano le specifiche e fanno domande; e si tiene conto del comportamento attuale del sistema, perché la nuova funzionalità non rompa quelle esistenti.

Il Manifesto Agile dà più valore alle voci a sinistra che a quelle a destra, e il BDD si allinea a ciascuna: ^[7]

Il TDD, base del BDD

Per capire perché si dice che “il BDD deriva dal TDD”, bisogna capire il TDD.

Il problema del test alla fine

Nell’approccio tradizionale il test arriva dopo ogni fase (test-last). In pratica viene compresso o saltato per ritardi, scadenze strette e pressione a consegnare. Il test di unità, che spetta allo sviluppatore, è di solito il primo a saltare, con giustificazioni come “sono uno sviluppatore, non un tester” o “il mio codice non ha difetti”. Il risultato è qualità compromessa, responsabilità concentrata sui tester, correzioni costose dopo la consegna e clienti insoddisfatti.

Prima il test

L’approccio test-first inverte l’ordine: invece di scrivere il codice e poi testarlo (dall’interno all’esterno), si scrive il test e poi il codice (dall’esterno all’interno). Compare nella Programmazione Estrema (XP) e nel TDD, formalizzato da Kent Beck: lo sviluppatore scrive il test di unità di un modulo prima di scriverne una sola riga, e poi scrive il codice con l’obiettivo di far passare il test. ^{[4] [5]}

Il ciclo Rosso, Verde, Refactoring

1. scegli il pezzo di codice da scrivere;
2. scrivi un test per quel pezzo;
3. esegui il test: fallisce, perché il codice non esiste ancora (rosso);
4. scrivi il minimo di codice per far passare il test (verde);
5. esegui tutti i test per assicurarti che passino ancora;
6. fai refactoring: togli le duplicazioni e migliora il codice;
7. ripeti per il pezzo successivo.

Ogni giro deve essere breve; un’ora di lavoro di solito contiene molti cicli.

Vantaggi del TDD

• lo sviluppatore deve capire il risultato atteso, e come testarlo, prima di scrivere codice;
• un componente è finito solo quando il test passa e il codice è stato rifattorizzato;
• dato che la suite gira a ogni refactoring, il riscontro su ciò che funziona ancora è costante;
• i test di unità fanno da documentazione sempre aggiornata;
• ogni difetto trovato riceve un test che lo riproduce, il che riduce il tempo di debugging e ne impedisce il ritorno;
• lo sviluppatore può cambiare il progetto e rifattorizzare in sicurezza, il che rende il software più facile da mantenere;
• dato che gran parte del test avviene durante lo sviluppo, il test prima della consegna si accorcia.

Dove il TDD lascia dubbi

Il punto di partenza sono le storie utente, che descrivono comportamenti. Con il solo TDD, lo sviluppatore resta con delle domande: quando testare? Cosa testare? Come sapere se una specifica è rispettata? Il codice porta valore al business? Qui entra in gioco il BDD.

Miti sul TDD

ATDD: prima l’accettazione

Lo sviluppo guidato dai test di accettazione (ATDD) definisce criteri e test di accettazione quando si creano le storie utente, all’inizio dello sviluppo. Il focus è sulla comunicazione e sulla comprensione comune tra clienti, sviluppatori e tester. ^[9]

Le pratiche centrali sono:

• discutere scenari del mondo reale per costruire una comprensione comune del dominio;
• usare questi scenari per arrivare ai criteri di accettazione;
• automatizzare i test di accettazione;
• concentrare lo sviluppo sul far passare questi test;
• usare i test come specifica viva, che facilita i cambiamenti.

Così i requisiti sono senza ambiguità e senza lacune funzionali, tutti vedono i casi speciali previsti dagli sviluppatori, e i test di accettazione guidano lo sviluppo.

Dal TDD al BDD

Dan North notò che i programmatori che praticavano il TDD si scontravano sempre con gli stessi dubbi: da dove cominciare, cosa testare e cosa no, quanto testare in una volta, come chiamare i test e come capire perché un test fallisce. La sua risposta fu cambiare il lessico: pensare in termini di comportamento, non di test. ^[3]

Ho trovato il passaggio dal pensare in termini di test al pensare in termini di comportamento così profondo che ho cominciato a chiamare il TDD BDD, sviluppo guidato dal comportamento.

Dan North, “Introducing BDD”, 2006 ^[3]

Il TDD si occupa di come funzionerà qualcosa; il BDD, del perché lo stiamo costruendo. Le risposte del BDD ai dubbi del TDD sono:

Il modello di storia

Come [ruolo]
Voglio [funzionalità]
Affinché [beneficio]

Cioè: quando la funzionalità viene eseguita, chi ottiene il beneficio è la persona nel ruolo.

Il modello di esempio

Dato un contesto iniziale,
Quando avviene un evento,
Allora garantisci alcuni risultati.

Partendo da un contesto, quando avviene un evento, sappiamo quali risultati devono esserci. Martin Fowler descrive questo formato come un modo di rappresentare i test che viene dalla specifica tramite esempi. ^[16]

Esempio: il bancomat di Dan North

Storia: Il cliente preleva contanti
  Come cliente,
  Voglio prelevare contanti al bancomat,
  Affinché non debba fare la fila in banca.

Scenario 1: Il conto è in attivo
  Dato che il conto è in attivo
  E la carta è valida
  E il bancomat contiene contanti
  Quando il cliente chiede contanti
  Allora il conto viene addebitato
  E i contanti vengono erogati
  E la carta viene restituita

Scenario 2: Il conto ha superato il limite di fido
  Dato che il conto è in rosso oltre il fido
  E la carta è valida
  Quando il cliente chiede contanti
  Allora viene mostrato un messaggio di rifiuto
  E i contanti non vengono erogati
  E la carta viene restituita

L’evento è lo stesso nei due scenari, ma il contesto cambia, e quindi cambiano i risultati. ^[3]

TDD × BDD

• Il TDD descrive come funziona il software.
• Il BDD descrive come l’utente usa il software, promuove collaborazione e comunicazione, dà rilievo agli esempi di comportamento e punta a specifiche eseguibili ricavate da quegli esempi.

Il ciclo dall’esterno all’interno

Il ciclo di sviluppo del BDD parte dall’esterno, dal comportamento che l’utente vede, e scende fino alle unità di codice. Steve Freeman e Nat Pryce lo chiamano doppio ciclo: un ciclo esterno di accettazione racchiude più cicli interni di TDD. ^[17]

1. scrivi un esempio di alto livello, di valore per il business (con Cucumber, per esempio), che diventa rosso;
2. scrivi un esempio di basso livello, di unità, per il primo passo dell’implementazione, anch’esso rosso;
3. implementa il codice minimo per far passare quell’esempio: verde;
4. scrivi il successivo esempio di basso livello che avvicina il passo 1 al successo;
5. ripeti i passi 3 e 4 finché l’esempio di alto livello diventa verde.

Lo stato rosso o verde funziona come un permesso:

• con i test di basso livello verdi, puoi scrivere nuovi esempi o rifattorizzare, ma senza aggiungere funzionalità durante il refactoring;
• con i test rossi, puoi modificare il codice solo per farli passare. Resisti alla tentazione di anticipare il test successivo, che ancora non esiste, o di creare funzioni che il cliente non ha chiesto.

Specifica tramite esempi

Gojko Adzic, autore di Specification by Example, la definisce come un insieme di pattern di processo che facilitano il cambiamento nei prodotti software, per garantire che si consegni il prodotto giusto in modo efficiente. Invece di affermazioni astratte, requisiti e test funzionali vengono catturati con esempi realistici, definiti in collaborazione. ^[6]

Si basa su un linguaggio ubiquo, concetto di Eric Evans: un lessico preciso e condiviso, creato da un team multidisciplinare e usato da tutti, nei requisiti, nel codice e nei test. ^[12] Gli esempi alimentano direttamente test automatizzati che riflettono il dominio di business, ed è per questo che la SbE si occupa insieme di costruire il prodotto giusto e di costruirlo bene.

Perché gli esempi

Gli esempi sono più facili da capire e più difficili da fraintendere. Diventano requisiti eseguibili, che si possono testare senza traduzione e restano in una documentazione viva. Il focus passa al prevenire i difetti, e non solo a rilevarli.

Vantaggi: più qualità, meno sprechi, meno rischio di difetti in produzione, impegno più mirato, cambiamenti più sicuri e maggiore coinvolgimento del business.

Quando usarla: funziona bene in business od organizzazioni complessi, anche su sistemi legacy. Funziona male per problemi puramente tecnici e per prodotti centrati sull’interfaccia grafica.

Esempi come test di accettazione

• una stessa illustrazione fa da requisito dettagliato e da test;
• l’avanzamento del progetto si misura in comportamenti: ogni test verifica un comportamento, e un test che passa significa che quel comportamento è pronto. Se il progetto richiede 100 comportamenti e 60 passano, è al 60%;
• i tester passano dal trovare difetti al prevenirli, partecipando al disegno della soluzione;
• l’automazione mostra subito l’impatto di un cambio di requisito.

I sei pattern di processo

1. Specificare in collaborazione: i Tre Amigos

L’obiettivo è che i diversi ruoli condividano comprensione e lessico, che ognuno contribuisca con la propria prospettiva e che la responsabilità delle funzionalità sia condivisa. Succede in un workshop di specifica noto come riunione dei Tre Amigos: business (analista o PO), sviluppo e test. ^[10]

Nella riunione, il business presenta requisiti e test della nuova funzionalità; i tre discutono e rivedono le specifiche; sviluppo e test segnalano ciò che manca. Tutti usano il linguaggio del dominio (con un glossario, se serve), cercano differenze e conflitti, evitano i dettagli di implementazione e arrivano a un consenso sul fatto che la funzionalità sia specificata abbastanza. La mappatura degli esempi aiuta a dare forma alla conversazione, con cartoncini per la storia, le regole, gli esempi e le domande aperte. ^[11]

2. Illustrare con esempi

Dato <una precondizione>
E <altre precondizioni>         # facoltativo
Quando <avviene un’azione o un evento>
Allora <una postcondizione>
E <altre postcondizioni>        # facoltativo

Ogni esempio descrive un comportamento del sistema ed è anche un criterio di accettazione. Il team discute gli esempi finché concorda che coprono il comportamento atteso.

3. Rifinire la specifica

• sii preciso; se un esempio diventa complesso, dividilo;
• usa la prospettiva del business ed evita i dettagli tecnici;
• considera condizioni positive e negative, valori limite e casi estremi;
• mantieni il lessico del dominio;
• discuti gli esempi con il cliente e tieni solo quelli che gli interessano, senza cercare di coprire tutte le combinazioni;
• specifica regole di business aggiuntive, come calcoli complessi e trasformazioni di dati;
• includi scenari non funzionali, come prestazioni e usabilità, quando ha senso.

4. Automatizzare gli esempi

Lo strato di automazione deve essere molto sottile: solo collegare la specifica al sistema sotto test. Concentrati sulla specifica, non sullo script; mostra chiaramente il legame tra input e output.

5. Validare spesso

Inserisci la validazione degli esempi nella pipeline, a ogni modifica. I principi sono testare presto, testare bene e testare spesso. Un comportamento è pronto solo quando il suo test passa.

6. Documentazione viva

Mantieni le specifiche brevi e semplici, organizzale, falle evolvere con il lavoro e rendile accessibili a tutto il team. Dato che si eseguono come test, non diventano mai obsolete senza che qualcuno se ne accorga.

Anti-pattern

Gli anti-pattern sono pratiche ricorrenti che sembrano ragionevoli ma creano problemi. Nella Specifica tramite esempi, i più comuni sono: ^[6]

Per evitarli, riunitevi per specificare con esempi, ripulite e migliorate gli esempi, scrivete il codice che li soddisfa, automatizzateli e ripetete per ogni storia. In pratica significa:

• Collaborare: business, sviluppo e test contribuiscono con le proprie prospettive; il processo vale più dei test stessi.
• Concentrarsi sul “cosa”: non cercare di coprire tutti i casi, mantieni gli esempi semplici e comprensibili agli utenti e tieni gli strumenti fuori dai workshop.
• Concentrarsi sul business: scrivi le specifiche al livello dell’intento di business, coinvolgi il business nella creazione e nella revisione e nascondi i dettagli nello strato di automazione.
• Essere preparati: i benefici non sono immediati, l’adozione è impegnativa e richiede tempo e investimenti, e l’automazione ha un costo.

Gherkin

Gherkin è il linguaggio usato per scrivere funzionalità, scenari e passi. Lo scopo è scrivere requisiti concreti. Confronta: ^[13]

• “Ai clienti deve essere impedito di inserire dati della carta non validi.”
• “Se il cliente inserisce un numero di carta che non ha esattamente 16 cifre, all’invio il modulo deve essere mostrato di nuovo con un messaggio che indica il numero corretto di cifre.”

La seconda frase non ha ambiguità, evita errori e si può testare. Gherkin esiste in decine di lingue, italiano compreso; basta indicare la lingua nella prima riga. ^[14]

Parole chiave

I file Gherkin sono testo semplice con estensione .feature. Ogni riga non vuota comincia con una parola chiave:

Funzionalità

Ha la parola chiave, un nome sulla stessa riga e una descrizione facoltativa (ma consigliata) nelle righe seguenti. Per convenzione, il file prende il nome della funzionalità in minuscolo, con trattini bassi: prelievo_al_bancomat.feature. Per individuare le funzionalità si può usare il modello di iniezione della funzionalità: Per <raggiungere un obiettivo>, come <tipo di utente>, voglio <una funzionalità>.

Scenario

Una funzionalità ha di solito da 5 a 20 scenari. Ognuno descrive un contesto (Dato), un’azione (Quando) e un risultato atteso (Allora); E e Ma aggiungono passi dello stesso tipo:

Scenario: Tentativo di prelievo con carta rubata
  Dato che ho 100 € sul conto
  Ma la mia carta non è valida
  Quando chiedo 50 €
  Allora la carta non deve essere restituita
  E devo essere invitato a contattare la banca

Ogni scenario deve avere senso ed eseguirsi da solo, senza dipendere dal fatto che un altro sia stato eseguito prima. Così i test sono più semplici, se ne può eseguire solo una parte e, a seconda del sistema, eseguirli in parallelo.

Schema dello scenario

Quando più scenari cambiano solo nei valori, usa uno schema: i segnaposto vanno tra < e > e i valori arrivano dalla tabella degli esempi, dove ogni riga diventa uno scenario.

# language: it
Funzionalità: Somma
  Schema dello scenario: Sommare due numeri
    Dato l’input "<input>"
    Quando la calcolatrice viene eseguita
    Allora l’output deve essere "<output>"

    Esempi:
      | input   | output |
      | 2+2     | 4      |
      | 98+1    | 99     |
      | 255+390 | 645    |

Cucumber e le definizioni dei passi

Cucumber è uno strumento libero a riga di comando che legge i file .feature ed esegue gli scenari sul sistema. Riunisce in un unico posto specifica eseguibile, test automatizzato e documentazione viva. ^[15]

Un tipico test di accettazione in Cucumber mostra la gerarchia: i test di accettazione si riferiscono a funzionalità, le funzionalità sono spiegate da scenari e gli scenari sono fatti di passi.

# language: it
Funzionalità: Registrazione
  La registrazione deve essere rapida e cordiale.

  Scenario: Registrazione riuscita
    I nuovi utenti devono ricevere un’e-mail di conferma
    ed essere salutati per nome.

    Dato che ho scelto di registrarmi
    Quando mi registro con dati validi
    Allora devo ricevere un’e-mail di conferma
    E devo vedere un messaggio di benvenuto personalizzato

Come funziona

• ogni passo in Gherkin ha bisogno di una definizione di passo: un pezzo di codice con un’espressione associata;
• quando esegue un passo, Cucumber cerca la definizione la cui espressione corrisponde al testo ed esegue il suo codice. La parola chiave (Dato, Quando, Allora) non entra nel confronto;
• parametri come {int} o {string} catturano valori dal testo e li passano al codice;
• se tutti i passi girano senza errori, lo scenario passa; alla fine, Cucumber riporta quanti scenari sono passati e cosa è fallito.

Cucumber ha implementazioni per diverse piattaforme, come Java (Cucumber-JVM), JavaScript (Cucumber.js) e Ruby, e si integra con strumenti come Selenium e Spring.

Strumenti

Un equivoco comune è pensare che il BDD sia uno strumento. Il BDD è un approccio di sviluppo; gli strumenti aiutano soltanto. Ci sono persino team che praticano la Specifica tramite esempi senza alcuno strumento. I più noti:

SpecFlow e Reqnroll

Per anni SpecFlow è stato lo strumento BDD per .NET: usava Gherkin, generava una classe di test per funzionalità e un metodo per scenario, trasformava i tag in categorie di test e gli schemi di scenario in test per riga. Tricentis ha ritirato SpecFlow, e Reqnroll è nato come ripartenza open source del progetto, compatibile con esso e con una migrazione semplice. ^[18]

Behave

In Behave, per Python, i file stanno in una cartella features: i file .feature con gli scenari, una cartella steps con le definizioni dei passi in Python e, facoltativamente, un file di ambiente con codice da eseguire prima e dopo passi, scenari o funzionalità. ^[19]

Concordion

Concordion, per Java, automatizza la Specifica tramite esempi con specifiche scritte in linguaggio naturale, con paragrafi e tabelle, senza richiedere il formato Dato/Quando/Allora. ^[20]

Ripasso veloce

Prova a rispondere prima di aprire ogni domanda.

Riferimenti

1. Giovani Perotto Mesquita, “Behavior Driven Development Tutorial”, GitHub Gist, testo originale di questo tutorial, gist.github.com/GiovaniPM/d115d35e2d4c0fe4062f8b6f98c84d82.
2. Tutorialspoint, “Behavior Driven Development Tutorial”, consultato il 25/09/2026, tutorialspoint.com/behavior_driven_development.
3. Dan North, “Introducing BDD”, 2006, dannorth.net/introducing-bdd.
4. Kent Beck, Test-Driven Development: By Example, Addison-Wesley, 2002.
5. Martin Fowler, “Test Driven Development”, martinfowler.com/bliki/TestDrivenDevelopment.html.
6. Gojko Adzic, Specification by Example, Manning, 2011, gojko.net/books/specification-by-example.
7. Manifesto per lo Sviluppo Agile di Software, 2001, agilemanifesto.org/iso/it/manifesto.html.
8. Agile Alliance, “Behavior Driven Development (BDD)”, glossario, agilealliance.org/glossary/bdd.
9. Agile Alliance, “Acceptance Test Driven Development (ATDD)”, glossario, agilealliance.org/glossary/atdd.
10. Agile Alliance, “Three Amigos”, glossario, agilealliance.org/glossary/three-amigos.
11. Matt Wynne, “Introducing Example Mapping”, blog di Cucumber, cucumber.io/blog/bdd/example-mapping-introduction.
12. Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, 2003.
13. Cucumber, “Gherkin Reference”, consultato il 25/09/2026, cucumber.io/docs/gherkin/reference.
14. Cucumber, “Localisation” (lingue di Gherkin), consultato il 25/09/2026, cucumber.io/docs/gherkin/languages.
15. Cucumber, “Step Definitions”, consultato il 25/09/2026, cucumber.io/docs/cucumber/step-definitions.
16. Martin Fowler, “GivenWhenThen”, martinfowler.com/bliki/GivenWhenThen.html.
17. Steve Freeman e Nat Pryce, Growing Object-Oriented Software, Guided by Tests, Addison-Wesley, 2009.
18. Reqnroll, sito ufficiale, consultato il 25/09/2026, reqnroll.net.
19. Behave, documentazione, consultato il 25/09/2026, behave.readthedocs.io.
20. Altri strumenti: Concordion, concordion.org; JBehave, jbehave.org; Behat, docs.behat.org.