Checklist de Decisão BDD
Use este checklist para decidir se o Desenvolvimento Orientado a Comportamento (BDD) com arquivos de funcionalidade Gherkin agrega valor em relação ao pytest puro para o seu projeto.
Como Usar Este Checklist
- Revise antes de adotar BDD para uma nova funcionalidade ou equipe.
- Pontue cada seção: se a maioria dos itens estiver desmarcada, mantenha o pytest.
- Reavalie quando os stakeholders solicitarem "documentação viva".
Alinhamento com Stakeholders
- Stakeholders não técnicos lerão os arquivos de funcionalidade. Analistas de produto, QA ou de negócios participam da revisão dos cenários.
- Cenários descrevem o comportamento do negócio, não cliques na UI. "Usuário recebe e-mail de confirmação" em vez de "Usuário clica no botão #3".
- A equipe concorda com o vocabulário Given-When-Then. Linguagem compartilhada entre negócios e engenharia.
- Critérios de aceitação já estão escritos em forma de cenário. BDD formaliza a prática existente, não a inventa.
Adequação Técnica
- Funcionalidades mapeiam para resultados visíveis ao usuário. Contratos de API, fluxos de trabalho ou regras de domínio - não refatorações internas.
- Configuração de dados de teste é gerenciável nas definições de passo. Configurações complexas podem indicar que testes unitários são melhores.
- Definições de passo permanecem DRY (Don't Repeat Yourself). Passos reutilizáveis entre funcionalidades sem copiar e colar.
- CI pode executar a suíte BDD em menos de 5 minutos. Suítes BDD lentas são ignoradas.
Custo-Benefício
- Existe orçamento de manutenção para os arquivos de funcionalidade. Cenários se desviam sem propriedade.
- O pytest sozinho não consegue expressar o comportamento com clareza. BDD adiciona legibilidade, não apenas estrutura.
- O tamanho da equipe suporta a sobrecarga. Equipes pequenas podem achar que pytest + nomes de teste descritivos são suficientes.
- Documentação viva é um objetivo declarado. Não apenas testes - documentação que se mantém atualizada.
Sinais de Alerta (NÃO adote BDD se)
- Apenas desenvolvedores lerão os testes. Use pytest com nomes descritivos em vez disso.
- Cenários duplicariam testes pytest 1:1. Duas suítes para manter sem ganho.
- Definições de passo se tornam uma segunda aplicação. Mais lógica nos passos do que no código de produção.
- Cenários instáveis corroem a confiança. Stakeholders param de ler os arquivos de funcionalidade.
FAQs
Quando o pytest puro é suficiente?
Quando apenas desenvolvedores leem os testes e o comportamento é lógica em nível de unidade, não fluxos de trabalho voltados para o usuário.
Posso usar BDD para APIs?
Sim. Cenários descrevem o comportamento de requisição/resposta HTTP. Boa opção para testes de contrato com stakeholders.
behave ou pytest-bdd?
behave: runner BDD independente. pytest-bdd: funcionalidades Gherkin dentro do pytest. Prefira pytest-bdd se já estiver usando pytest.
Quantos cenários antes do BDD compensar?
Aproximadamente 10+ cenários de aceitação com envolvimento de stakeholders. Abaixo disso, pytest é suficiente.
Posso misturar BDD e pytest?
Sim. BDD para testes de aceitação; pytest para testes unitários e de integração. A maioria dos projetos deveria.
E se os cenários ficarem longos?
Divida em cenários menores ou use Scenario Outline. Cenários longos são um sinal de design ruim.
BDD é o mesmo que testar?
BDD começou como uma prática de design. A suíte de testes é um subproduto da especificação do comportamento.
Como faço um piloto de BDD?
Um arquivo de funcionalidade para o próximo épico. Avalie o custo de manutenção após um sprint.
BDD substitui testes unitários?
Não. BDD cobre o comportamento de aceitação. Testes unitários cobrem lógica, casos de borda e caminhos de erro.
E sobre Cucumber?
Cucumber é o equivalente nos ecossistemas JVM/JS. Python usa behave ou pytest-bdd.
Relacionados
- Sintaxe Gherkin - escrita de arquivos de funcionalidade
- Configuração behave / pytest-bdd - configuração de ferramentas
- Melhores Práticas BDD - manutenção de cenários
- Melhores Práticas de Teste - convenções do pytest
Versões do 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+.