Comece pela conversa, não pela sintaxe

Produto, desenvolvimento e teste exploram uma regra e discutem exemplos que deixam claro o resultado esperado. Essa conversa revela ambiguidades, exceções e vocabulário compartilhado. O exemplo pode começar em linguagem comum, quadro ou documento; automatizá-lo só faz sentido quando oferece valor como verificação repetível.

BDD concentra-se em comportamento observável e valor. Não exige um framework específico, interface gráfica ou que todo cenário seja executado como teste de ponta a ponta.

Estruture um cenário com contexto, ação e resultado

Gherkin organiza especificações em funcionalidades e cenários. Given descreve contexto, When a ação relevante e Then o resultado observável:

Funcionalidade: confirmação de pedidos

  Cenário: cliente confirma um pedido válido
    Dado que o pedido está aberto e possui itens
    Quando o cliente confirma o pedido
    Então o pedido passa para o estado confirmado
    E uma confirmação é registrada

Prefira linguagem do domínio e um resultado que possa ser observado. Evite detalhes de tela, tabelas ou chamadas internas se não fazem parte do requisito. Mantenha cenários independentes; preparação compartilhada oculta costuma tornar a especificação difícil de entender.

Da especificação à automação

Em .NET, ferramentas compatíveis com Gherkin podem associar passos do cenário a código de teste. A configuração e o ecossistema variam; verifique manutenção e compatibilidade da ferramenta escolhida com a versão de .NET e seu runner. Um step definition deve traduzir o vocabulário do cenário para a aplicação, não esconder uma mini linguagem de programação.

Nem todo exemplo precisa ser automatizado via navegador. Regras de domínio podem ser verificadas por testes unitários rápidos; contratos e integrações por testes apropriados às suas fronteiras. Automatize a camada mais baixa capaz de dar confiança sobre o comportamento e mantenha poucos cenários de ponta a ponta.

Exemplos executáveis não substituem bons critérios

Um cenário excessivamente técnico, com muitos passos e valores repetidos, fica caro de alterar. Um cenário vago como “o sistema funciona” não informa o comportamento. Divida exemplos quando cada um cobre uma regra distinta, use tabelas de exemplos com moderação e prefira nomes claros a abstrações genéricas nos steps.

Se o requisito muda, revise também os exemplos e a automação que representam o comportamento atual. Não mantenha especificações como documentação desatualizada que sempre passa, mas já não descreve o produto.

BDD e TDD trabalham em escalas diferentes

BDD ajuda a esclarecer quais comportamentos e exemplos importam para o produto. TDD usa um ciclo curto de testes e código para implementar uma unidade de comportamento com feedback. Uma equipe pode explorar um cenário BDD e então usar TDD para desenhar as regras internas, sem duplicar cada exemplo em todos os níveis. Veja TDD em .NET e testes unitários.

Documentação e leituras relacionadas