BDD - TDD de uma forma BDD

No TDD, o termo “Testes de Aceitação” é enganoso. Os testes de aceitação realmente representam o comportamento esperado do sistema. Nas práticas Agile, a colaboração de toda a equipe e as interações com o cliente e outras partes interessadas são enfatizadas. Isso deu origem à necessidade de utilização de termos que sejam facilmente compreendidos por todos os envolvidos no projeto.

TDD faz você pensar sobre o necessário Behavior e, portanto, o termo 'comportamento' é mais útil do que o termo ‘Test’. BDD é Test Driven Development com um vocabulário que se concentra no comportamento e não nos testes.

Nas palavras de Dan North, “descobri que a mudança do pensamento em testes para o pensamento comportamental foi tão profunda que comecei a me referir ao TDD como BDD, ou Behavior Driven Development.” TDD se concentra em como algo vai funcionar, BDD se concentra em por que o construímos.

O BDD responde às seguintes perguntas frequentemente enfrentadas pelos desenvolvedores -

Questão	Responda
Onde começar?	De fora para dentro
O que testar?	Histórias de usuários
O que não testar?	algo mais

Essas respostas resultam na estrutura da história da seguinte maneira -

Story Framework

Como um [Role]

eu quero [Feature]

de modo a [Benefit]

Isso significa, 'Quando um Feature é executado, o resultado Benefit é para a pessoa que joga o Role.'

O BDD responde ainda às seguintes questões -

Questão	Responda
Quanto custa para testar de uma vez?	muito pouco focado
Como chamar seus testes?	modelo de frase
Como entender por que um teste falha	documentação

Essas respostas resultam na estrutura de exemplo da seguinte maneira -

Example Framework

Given algum contexto inicial,

When um evento ocorre,

Then garantir alguns resultados.

Isso significa, 'começando com o contexto inicial, quando um determinado evento acontece, sabemos quais são os resultados should be. '

Assim, o exemplo mostra o comportamento esperado do sistema. Os exemplos são usados ​​para ilustrar diferentes cenários do sistema.

História e Cenários

Vamos considerar a seguinte ilustração de Dan North sobre um sistema ATM.

História

As a cliente,

I want para retirar dinheiro de um caixa eletrônico,

so that Não preciso esperar na fila do banco.

Cenários

Existem dois cenários possíveis para esta história.

Scenario 1 - Conta com crédito

Given a conta está em crédito

And o cartão é válido

And o distribuidor contém dinheiro

When o cliente pede dinheiro

Then garantir que a conta seja debitada

And garantir que o dinheiro seja dispensado

And garantir que o cartão seja devolvido

Scenario 2 - A conta está a descoberto após o limite de descoberto

Given a conta está a descoberto

And o cartão é válido

When o cliente pede dinheiro

Then garantir que uma mensagem de rejeição seja exibida

And garantir que o dinheiro não seja distribuído

And garantir que o cartão seja devolvido

O evento é o mesmo em ambos os cenários, mas o contexto é diferente. Portanto, os resultados são diferentes.

Ciclo de Desenvolvimento

O Ciclo de Desenvolvimento do BDD é um outside-in aproximação.

Step 1- Escreva um exemplo de valor de negócios de alto nível (externo) (usando Cucumber ou RSpec / Capybara) que fica vermelho. (RSpec produz uma estrutura BDD na linguagem Ruby)

Step 2 - Escreva um exemplo RSpec de nível inferior (interno) para a primeira etapa de implementação que fica vermelho.

Step 3 - Implemente o código mínimo para passar esse exemplo de nível inferior, veja-o ficar verde.

Step 4 - Escreva o próximo exemplo de RSpec de nível inferior empurrando para passar na Etapa 1 que fica vermelho.

Step 5 - Repita as etapas Etapa 3 e Etapa 4 até que o exemplo de alto nível na Etapa 1 fique verde.

Note - Os seguintes pontos devem ser mantidos em mente -

• Red/green state é um status de permissão.

• Quando seus testes de baixo nível são verdes, você tem permissão para escrever novos exemplos ou refatorar a implementação existente. Você não deve, no contexto da refatoração, adicionar nova funcionalidade / flexibilidade.

• Quando seus testes de baixo nível estão vermelhos, você tem permissão para escrever ou alterar o código de implementação apenas para tornar os testes existentes verdes. Você deve resistir ao impulso de escrever o código para passar em seu próximo teste, que não existe, ou implementar recursos que você possa considerar bons (o cliente não teria perguntado).