Gherkin para Código

O fluxo de trabalho Gherkin-para-código começa com um cenário falho, implementa definições de passos mínimas e, em seguida, constrói o código da aplicação até que o cenário passe. Este é o desenvolvimento "outside-in" com critérios de aceitação executáveis.

Receita

1. Escrever cenário (falha - sem passos)
2. Implementar stubs de passos (falha - NotImplementedError)
3. Construir código da aplicação (cenário passa)
4. Refatorar passos e aplicação juntos

Quando usar isso:

• Nova funcionalidade com critérios de aceitação claros
• Equipe pratica BDD como disciplina de design
• Stakeholders revisam cenários antes da implementação

Exemplo de Trabalho

# features/discount.feature
Feature: Volume discount
  Scenario: 10% discount for orders over 1000
    Given a customer with a cart total of 1500.00
    When the discount is calculated
    Then the discount amount is 150.00
    And the final total is 1350.00

# Passo 1: passos falhos
from pytest_bdd import scenarios, given, when, then, parsers
 
scenarios("../discount.feature")
_cart = {}
 
@given(parsers.parse("um cliente com um total de carrinho de {total:f}"))
def cart_total(total):
    _cart["total"] = total
 
@when("o desconto é calculado")
def calculate():
    from myapp.discount import apply_volume_discount
    _cart["result"] = apply_volume_discount(_cart["total"])
 
@then(parsers.parse("o valor do desconto é {amount:f}"))
def check_discount(amount):
    assert _cart["result"]["discount"] == amount
 
@then(parsers.parse("o total final é {total:f}"))
def check_final(total):
    assert _cart["result"]["final"] == total

# Passo 2: código mínimo da aplicação
def apply_volume_discount(total: float) -> dict[str, float]:
    if total > 1000:
        discount = total * 0.10
    else:
        discount = 0.0
    return {"discount": discount, "final": total - discount}

O que isso demonstra:

• O cenário dita o que construir
• Os passos são uma cola fina sobre apply_volume_discount
• O código da aplicação é a menor implementação para passar
• Refatorar após o verde

Mergulho Profundo

Fluxo Outside-In

Cenário (aceitação)
  -> Definições de passos (cola)
    -> Função de serviço (domínio)
      -> Testes unitários (casos de borda)

Quando Adicionar Testes Unitários

• Após o cenário passar, adicione testes unitários pytest para casos de borda (limite 0, 1000, negativo)
• Cenários cobrem caminhos felizes; testes unitários cobrem limites e erros

Armadilhas

• Implementar tudo nos passos - monólito não testável no arquivo de passos. Correção: extrair para módulos myapp/ imediatamente.
• Escrever todos os cenários antecipadamente - BDD em cascata. Correção: um cenário por história; iterar.
• Pular a fase de passo falho - verde sem verificação. Correção: executar o cenário, confirmar que ele falha pela razão correta.
• Cenário muito detalhado - "Dado que a linha 42 do banco de dados existe". Correção: linguagem de domínio: "Dado um cliente premium."
• Sem testes unitários após BDD - lacunas nos limites. Correção: BDD + testes unitários pytest se complementam.

Alternativas

FAQs

Relacionados

• Definições de Passos - escrevendo passos
• Sintaxe Gherkin - autoria de cenários
• Asserções e Estrutura de Teste - complemento de teste unitário
• Melhores Práticas de BDD - manutenção

Versões da 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+.