Melhores Práticas de BDD para Seniores: Guia Prático

Melhores práticas de BDD para seniors

1. Alinhamento de domínio e linguagem ubíqua

Em níveis mais avançados, BDD é uma forma de contar a história do domínio com a mesma linguagem que os negócios utilizam. Minha prática é manter a
terminologia estável e compartilhada entre equipes, evitando termos de implementação. Isso cria uma base de entendimento comum que reduz retrabalho e drift conceitual.

Construir um glossário vivo com termos do domínio (entidades, regras, estados de negócio) e mantê-lo acessível a todas as personas envolvidas.
Padronizar termos-chave: cada conceito de negócio deve possuir exatamente um rótulo na linguagem ubíqua.
Realizar revisões regulares de vocabulário com representantes de negócio e engenharia, buscando consenso e clareza.
Assegurar que os cenários reflitam regras de negócio, não detalhes de implementação ou tecnologia.

2. Estrutura de cenários: granularidade, organização e reutilização

Cenários devem ser legíveis, previsíveis e fáceis de manter. A granularidade importa: cada cenário deve validar uma única regra de negócio ou aspecto crítico.

Use Background para estabelecer contexto comum entre cenários de uma mesma funcionalidade.
Prefira cenários curtos e atômicos ao invés de blocos grandes que misturam várias regras.
Adote Scenario Outline para variações de dados, mantendo o modelo de Given/When/Then claro.
Evite duplicação de dados: externalize dados de entrada para tabelas de Examples ou para campos de dados compartilhados.

3. Especificações como documentação viva

As especificações devem acompanhar a evolução do domínio, servindo como referência para stakeholders e para a equipe técnica. Mantenha
a documentação alinhada aos termos de negócio e vincule-a aos cenários relevantes para facilitar consultas rápidas.

Utilize tags para categorizar cenários (ex.: @regra-de-negocio, @fluxo-CRUD, @crítico) e facilitar filtragem.
Crie links cruzados entre requisitos, histórias e cenários para fornecer visão integrada do comportamento esperado.
Mantenha a nomenclatura dos cenários estável; renomeações devem ser comunicadas e endereçadas com cuidado para evitar drift.
Documente cenários de exceção e casos de falha esperados como parte da narrativa de robustez do domínio.

4. Manutenção, evolução e governança de BDD

A governança de BDD deve ser simples, previsível e descendente do domínio. Foque na clareza de nomes, na gestão de dados de teste e na organização de
cenários para facilitar revisões e evolução ao longo do tempo.

Renomeie cenários de forma explícita quando o entendimento do negócio mudar; registre o porquê da mudança.
Gestão de dados de teste: use dados estáveis, com variações controladas, para evitar flertes com estados inexistentes no domínio.
Versionamento de specs: trate as features como artefatos sob controle de versão, com revisão de mudanças associadas a regras de negócio.
Defina uma cadência de revisão de cenários críticos e de alta frequência para evitar drift entre domínio e especificações.

Exemplo prático de boa prática de escrita de Gherkin

Abaixo apresento um exemplo mínimo de feature bem estruturada. Observe a separação entre dados, cenários e variações com Outline.


Feature: Cadastro de usuário com regras de negócio

  Background:
    Dado que existem categorias de usuários no sistema

  Scenario: Criar usuário com dados válidos
    Dado que o usuário tem email "joao@example.com" e senha "Senha$2024"
    Quando eu criar o usuário
    Então o usuário deve ser persistido com id não nulo

  Scenario Outline: Validar e-mails inválidos
    Dado que o usuário tem email "" e senha "Senha$2024"
    Quando eu tentar criar o usuário
    Então ocorre erro de validação com mensagem ""

  Examples:
    | email              | mensagem         |
    | "joao"             | "Email inválido" |
    | "joao@exemplo"     | "Email inválido" |
    | "joao@example..com" | "Email inválido" |