O BDD, na sua essência, é uma metodologia de desenvolvimento de software com o objetivo de orientar (ou orientar) o código a partir de exemplos de como o sistema é usado. Não tem nada a dizer sobre a aparência real da interface do usuário (que pode ser considerada como um simples "controlador" para seu aplicativo e poderia, em teoria, ser facilmente trocada por uma API REST, um navegador-ui ou qualquer coisa através de qual o usuário pode interagir com o aplicativo). Portanto, a partir da interface do usuário pode ser bastante enganador se você tentar praticar o BDD.
Pense na sua interface do usuário como uma camada fina que não contém lógica de negócios e, em vez disso, concentre-se em direcionar as "entranhas" do aplicativo. Essa é a lógica que você descreve na etapa (3) do seu fluxo de trabalho.
Por exemplo, imagine que esse seja um aplicativo de compras e o comportamento final que você gostaria de conduzir é comprar um produto. Isso requer poder dar o comando do sistema para adicionar um produto a uma "cesta", podendo pagar por etc. "Adicionar Produto X ao Carrinho" e "Pagar pelo meu Carrinho" são comandos que você pode dar ao sistema independentemente da interface do usuário.
Mesmo se você já especificou a interface do usuário - você pode / deve identificar os comandos dados ao sistema. É essencial conceituar o sistema em termos de lógica de negócios para que você não se distraia com detalhes de como a interface do usuário funcionará (você pode pensar nisso mais tarde).
Cada um desses comandos identificados se torna o When
no cenário Given/When/Then
. A ação que é finalmente testada quando o pacote é executado.
Identifique as regras de negócios - elas ajudarão você a entender as condições prévias que precisam ser atendidas para cada comando para ter o resultado esperado. Digamos que você tenha uma regra de negócios sobre os clientes que recebem uma Torradeira gratuita em todos os Microondas quando uma venda está em andamento:
Background:
Given the price of a microwave oven is £100
And the price of a toaster is £10
Scenario: Customers get free toaster if they buy a microwave
Given the winter sale starts on Sun 31st Dec at 9am
When I buy a microwave oven on Sun 31st Dec at 9am
Then my basket should contain the following line items
| Product | Price |
| Microwave oven | £100 |
| Toaster | £0 |
Scenario: Customers do not get free toaster if they buy a microwave before sale
Given the winter sale starts on Sun 31st Dec at 9am
When I buy a microwave oven on Sun 31st Dec at 8am
Then my basket should contain the following line items
| Product | Price |
| Microwave oven | £100 |
| Toaster | £10 |
Nesses cenários, você pode começar a escrever o código. Nas etapas determinadas, você configura os produtos com seus preços e a regra de vendas.
Em sua etapa When
, você executa a ação - chamando o código diretamente (desenvolvimento e feedback mais rápidos), chamando uma API ou automatizando o navegador real (o feedback mais lento e demorado)
Em sua etapa Then
, você afirma que o resultado aconteceu conforme o esperado - isso pode envolver a inspeção do conteúdo da persistência de dados e, provavelmente, a resposta do sistema ou da interface do usuário.
Construir o aplicativo dessa maneira força você a pensar bastante antes (a lógica de negócios), mas a codificação é mais fácil porque você simplesmente precisa fazer os cenários (que se tornam testes neste momento) passarem. Seu código é guiado literalmente pelos cenários / exemplos. / Quando eles passam você pode ter certeza de que o sistema funciona corretamente - vá e construa uma interface do usuário que permitirá aos clientes fazer o que os cenários dizem.