Melhores Práticas de BDD
Regras para suítes de BDD que permanecem legíveis para stakeholders e manteníveis para desenvolvedores.
Como Usar Esta Lista
- Aplique ao escrever ou revisar arquivos de funcionalidade (feature files) e definições de passos (step definitions)
- Se a maioria dos itens estiver desmarcada, considere continuar com pytest
- Revise o inventário de cenários trimestralmente para funcionalidades obsoletas
A - Qualidade de Cenários
- Cenários descrevem comportamento, não implementação. "Fatura é criada" não "POST /api/v2/invoices retorna 201."
- Máximo de 5-7 passos por cenário. Cenários mais longos são divididos em múltiplos casos.
- Passos Given declarativos. "Dado um cliente premium" não "Dado que insiro linha na tabela de clientes."
- Um resultado por cenário. Múltiplas asserções Then são aceitáveis se verificarem um único comportamento.
B - Definições de Passos
- Passos são "cola" fina. A lógica de negócio reside nos módulos da aplicação.
- Reutilize passos comuns. Passos de autenticação, cliente de API e asserção são compartilhados entre funcionalidades.
- Parsers tipados para parâmetros.
{amount:f}não análise de string no corpo do passo. - Contexto novo por cenário. Nenhum estado vaza entre execuções.
C - Organização
- Arquivos de funcionalidade agrupados por capacidade.
features/billing/,features/auth/. - Tags para smoke, slow e wip. CI executa smoke no PR; suíte completa no main.
- Scenario Outline apenas para variações de dados. Não para casos de teste não relacionados.
- Background para configuração compartilhada. Evite repetir Given em cada cenário.
D - Processo
- Cenários escritos antes da implementação. BDD "outside-in", não testes retroativos.
- Stakeholders revisam arquivos de funcionalidade. Documentação viva permanece atualizada.
- Testes unitários complementam BDD. Casos extremos e caminhos de erro em pytest.
- Exclua cenários para funcionalidades removidas. Cenários obsoletos corroem a confiança.
E - CI & Manutenção
- BDD executa em CI. Smoke no PR; aceitação completa no main ou noturno.
- Testes em memória são preferíveis. TestClient em vez de acessar APIs de staging em CI.
- Cenários instáveis corrigidos ou quarentenados.
@wipexcluído até ficar estável. - Relatórios publicados como artefatos. Relatórios HTML/Cucumber para visibilidade do stakeholder.
FAQs
Como BDD difere de testes de integração?
Cenários BDD são especificações de aceitação legíveis por stakeholders. Testes de integração são focados no desenvolvedor.
Quantos arquivos de funcionalidade?
Um por área de capacidade. 5-15 cenários por arquivo.
Desenvolvedores escrevem Gherkin?
Dev + produto juntos. Desenvolvedores são donos das definições de passos.
Como prevenir a explosão de passos?
Parametrize os passos. Revise o inventário de passos mensalmente; mescle duplicatas.
Apenas inglês?
Palavras-chave Gherkin são em inglês. O texto do passo pode usar linguagem de domínio acordada pela equipe.
Como lidar com versionamento de API em passos?
Oculte a versão nas definições de passos. Cenários permanecem agnósticos à versão.
BDD pode testar requisitos não funcionais?
Limitado. Performance e segurança são mais adequadas a ferramentas dedicadas. BDD para comportamento funcional.
Como integrar novos cenários?
Copie o arquivo de funcionalidade mais próximo. Siga as convenções de nomenclatura e reutilização de passos.
E BDD para aplicativos móveis?
Use passos com linguagem de domínio. Detalhes da UI ocultos na camada de definição de passos (Appium, etc.).
Quando aposentar o BDD?
Se os stakeholders pararem de ler os cenários e o custo de manutenção exceder o valor, consolide para pytest.
Relacionados
- Checklist de Decisão BDD - critérios de adoção
- Sintaxe Gherkin - escrevendo cenários
- Gherkin para Pipeline de CI - automação
- Melhores Práticas de Teste - complemento para pytest
Versões de Stack: Esta página foi escrita para Python 3.14.0, FastAPI 0.115+, Django 5.2, Flask 3.1, Pydantic 2, PyTorch 2.6+, pandas 2.2+, Polars 1.x, ruff 0.9+, e uv 0.6+.