1) Escrever cenários longos demais (fatiar é qualidade)

Cenários gigantes viram diagnóstico difícil: quando falha, ninguém sabe onde quebrou.

• Reduza o escopo: cada cenário deve validar uma regra de negócio específica.
• Evite “workflows completos” em uma única execução: prefira passos menores e combináveis.
• Dê nome a intenções: se o teste tem muitas condições, provavelmente você está misturando responsabilidades.
• Quando necessário, crie mais cenários para variações (ex.: sucesso, rejeição, limite, reprocessamento).

2) Tratar BDD como teste de implementação (linguagem do domínio, sempre)

BDD não é para “seguir o código”; é para descrever comportamento do sistema em termos que o negócio reconhece.

• Evite detalhes técnicos como nomes de tabelas, colunas, rotas internas e classes.
• Prefira verbos e conceitos do domínio: “o pedido é aprovado”, “a senha é redefinida”, “o pagamento é recusado”.
• Consistência de vocabulário: se o domínio chama de “assinatura”, não misture com “plano” no meio dos cenários.
• Se a frase começa a explicar a arquitetura, você perdeu o foco.

3) Tornar cenários frágeis (dados, tempo e ambiente)

Falhas intermitentes custam confiança. E sem confiança, ninguém mantém — e o BDD morre devagar.

• Controle o tempo: cenários que dependem de “agora” e fuso horário tendem a quebrar.
• Use dados determinísticos: evite geração aleatória sem seed e cenários que dependem de ordem de execução.
• Isolamento de estado: cada cenário deve começar de um estado conhecido (limpar/seed por execução).
• Evite dependências externas sempre que possível (serviços, filas, integrações). Quando não der, isole e trate falhas previsivelmente.
• Reduza “asserts indiretos”: confirme o resultado de negócio, não efeitos colaterais inesperados.

Feature: Cadastro de usuário
  Scenario: E-mail não pode ser reutilizado
    Given que não existe um usuário com o e-mail "ana@exemplo.com"
    When o usuário tenta cadastrar com o e-mail "ana@exemplo.com"
    Then o cadastro deve ser recusado
    And o sistema deve exibir a mensagem "E-mail já cadastrado"

Repare que o foco está no comportamento. O teste não precisa saber como o e-mail é armazenado,
nem como a validação é implementada.

4) Ignorar a manutenção (passos, regras e evolução do produto)

BDD só entrega valor contínuo se o custo de mudança for baixo e previsível.

• Passos reutilizáveis devem ser genéricos o suficiente, mas não “mágicos”. Se um passo funciona para um único caso, ele merece ser específico.
• Evite passos com múltiplas responsabilidades: “Given o usuário está pronto” pode esconder lógica demais.
• Evolua os cenários junto com a regra: se o domínio muda, ajuste o BDD para refletir a nova intenção — não “conserte” o teste para passar.
• Crie cobertura para regras novas, não apenas para fluxos. BDD é excelente para limites e exceções.
• Revise periodicamente: remova cenários obsoletos e agrupe variações relevantes.

Checklist rápido antes de colocar em produção

• O cenário diz “o que” acontece, não “como” acontece?
• Ele é curto e focado em uma regra de negócio?
• Começa do estado conhecido e termina com assertivas claras?
• Não depende de ordem ou de dados que podem mudar?
• A falha é diagnosticável em minutos (mensagens e variações bem nomeadas)?