BDD (Behaviour-Driven Development) é uma técnica colaborativa para definir e implementar sistemas através da descrição do seu comportamento, utilizando linguagem de negócios em cenários e exemplos para esclarecer os requisitos. Se associado à automação de testes funcionais, o BDD permite a geração de documentação viva, que se mantém relevante e atualizada durante a vida da aplicação.
2. Ana Carolina Hermann
anah@dbserver.com.br
Parte I
Introdução
Sintaxe básica
Vantagens
Dinâmica: BDD Warriors
Parte II
Dinâmica: Example Mapping
Formas de uso
Automação
Lições aprendidas
Parte III
Sintaxe avançada
Dinâmica: Escrita de Cenários
3. Técnica para implementar uma aplicação através da
descrição do seu comportamento do ponto de vista dos
stakeholders
Iniciou a partir do TDD: como saber o que testar?
Evolução: foco na comunicação entre as pessoas
Usos:
Análise: levantamento de requisitos
Desenvolvimento: guia de implementação
Testes: automação/testes de regressão
4. Funcionalidade: <Título>
Eu, como um <papel>,
Quero <funcionalidade>
Para que <benefício>
Cenário: <Título do Cenário>
Dado que… tenho uma situação inicial
Quando ... ocorre um evento
Então… deve... acontecer o resultado esperado
5. Funcionalidade: US001_Cobrança
Eu, como funcionário do setor Financeiro,
Quero gerar a cobrança anual
Para que possamos receber o valor devido
Critérios de aceitação:
O sistema deve gerar parcelas a partir do valor para o ano
atual
Deve ser possível realizar desconto por categoria
6. Cenário: Deve gerar cobrança
Dado que o valor anual é 100,00
Quando gerar a cobrança anual
Então deve ser criada uma parcela de 50,00 para janeiro
E deve ser criada uma parcela de 50,00 para julho
Cenário: Deve gerar cobrança com desconto
Dado uma categoria com desconto de 90,00
E que o valor anual é 100,00
Quando gerar a cobrança anual
Então deve ser criada uma parcela de 10,00 para janeiro
7. Aproximar a área técnica da área de negócios através de
Linguagem ubíqua
Criação colaborativa de cenários: Três amigos, Example Mapping
Entendimento compartilhado
Esclarecer cenários complexos de forma sucinta através de
exemplos
Focar no que agrega valor
Fornecer um guia de testes para o desenvolvedor
Documentação viva com uso de automação
8. Jogo de cartas print&play disponível sob Creative Commons em
https://bddwarriors.wordpress.com/
Regras em vídeo: https://goo.gl/AwqfkA
Objetivos:
Ajudar na popularização do BDD
Fixar a estrutura básica da sintaxe
Prevenir o apocalipse zumbi
Demonstrar a construção conjunta de cenários
9. Dois a seis jogadores
Cada um recebe cinco cartas e uma pilha de fichas
para identificação
Quem viu filme de Ficção Científica, Fantasia ou
Terror mais recentemente começa o jogo
11. Cristian
Gabriel
Ana
1 pt
Então ____ deve se transformar em ______
2 pts
Quando ____________
(Jogador pode continuar o cenário ou criar um
novo)
12. Cristian
Gabriel
Ana
1 pt
Então ____ deve se transformar em ______
1 pt
Dado um vampiro ____________
2 pts
Quando ____________
(Jogador deve ler o cenário
completando os espaços)
13. Cristian
Gabriel
Ana
1 pt
Então ____ deve se transformar em ______
1 pt
Dado um vampiro ____________
2 pts
Quando ____________
Cristian:
1 ponto (carta) +
2 pontos (completar cenário)
Gabriel:
2 pontos (carta)
Ana:
1 ponto (carta)
14. 3 pts
____ sorvete ____________
Cartas Coringa:
Somente pode ser jogada ao
completar um cenário!
Cenário: Comprar duas cartas
Dado que é a sua vez
Quando jogar essa carta
Então compre duas cartas e descarte qualquer
uma carta da sua mão
Cartas de Ação:
Siga as instruções na carta
16. Técnica para estruturar a conversa em torno de uma
estória
3 Amigos – Negócios, Teste, Desenvolvimento
Estória
Regra
Exemplo
Pergunta
17. Sacar dinheiro da
conta
Cliente normal não
pode sacar mais
que o saldo
Saque maior que o
saldo
Limite de conta
especial é fixo?
Cliente especial
pode atingir o
limite
Saque igual ou
menor ao saldo
Deve imprimir
comprovante
Limite 100
Saldo 10
Saque 110 -> OK
Limite 100
Saldo 10
Saque 120 -> NOK
Estória Perguntas
Regras
Exemplos
18. Visitantes pagam estacionamento por hora, até 2 horas é
um valor fixo, depois cobra hora adicional até um limite de
31 reais.
19. Entendimento compartilhado
Captura das informações da conversa
Interativo
Simplicidade: sem sintaxe Gherkin e sem detalhes de
implementação
Visualização do estado da estória
Muitos post-its rosas – muita incerteza para começar?
Muitos post-its azuis – estória grande demais?
Muitos post-its verdes por regra – regra abrangente demais?
21. Funcionalidade: US001_Gerar Cobrança
Eu, como funcionário do setor Financeiro,
Quero gerar a cobrança anual
Para que possamos receber o valor devido
Cenário: US001_Gerar cobrança normal
Dado…
…
Cenário: US001_Gerar cobrança com
desconto
Dado…
….
Funcionalidade: US002_Consultar Cobrança
Eu, como funcionário do setor Financeiro,
Quero consultar a cobrança
Para saber o que está em aberto
Cenário: US002_Consultar por período
Dado…
…
Cenário: US002_Consultar por situação
Dado…
….
Arquivo .feature por estória com
múltiplos cenários
Outros documentos:
protótipo de interface, padrão de sistema
22. BDD não gera documentação extensiva
Detalhar os cenários importantes/diferentes
BDD/Automação não substitui testes
Estilo imperativo x Estilo declarativo
Como x para quê
Detalhado x resumido
…
E informei dados do funcionário
Quando salvar o funcionário
…
…
E preenchi nome “Ana Carolina”
E preenchi sobrenome “Hermann”
E selecionei a profissão “Dev.”
Quando cliquei no botão “Salvar”
…
23. Pode haver BDD sem automação!
Ferramentas: Cucumber/SpecFlow/etc.
Exige mais tempo e conhecimento técnico da equipe
Vantagens:
• Testes de regressão
• Documentação viva
▪ Testes quebram ao alterar a especificação
▪ Especificação quebra ao alterar a aplicação
24. Tela
Maior tempo de execução
▪ Pirâmide de testes!
Regras mais importantes
Interface precisa estar estável
Serviço
Maior cobertura
Regras de negócio
Guia o desenvolvimento
▪ Testes de regressão = bônus!
UI
Serviço
Unitários
25. Colaboração!
Treinar a equipe
Dojos de 1h usando uma US da sprint
Alinhamento para entender automação
Depois que você sai do básico, não existe padrão
Melhoria contínua!
27. Contexto
Passos em comum que acontecem antes de cada cenário
Parâmetros
Permite reutilização na automação
Tabelas como parâmetros
Forma de estruturar dados quando há vários parâmetros
Esquema do Cenário
Repete o mesmo cenário com valores diferentes
28. Contexto:
Dado que o valor anual para 2016 é 100,00
Cenário: US001_Deve gerar cobranças
Dado um cliente com categoria “Efetivo”
Quando gerar a cobrança anual
Então devem ser criadas as seguintes parcelas a pagar
| Valor | Exercício |
| 50,00 | 01/2016 |
| 50,00 | 07/2016 |
Cenário: US001_Deve gerar cobrança com desconto
Dado um cliente com categoria “Aposentado”
E a categoria “Aposentado” tem desconto de 90,00
Quando gerar a cobrança anual
Então devem ser criadas as seguintes parcelas a pagar
| Valor | Exercício |
| 10,00 | 01/2016 |
29. Contexto:
Dado que o valor anual para 2016 é 100,00
Esquema do Cenário: US001_Deve gerar exercício para o mês
seguinte
Dado um cliente com categoria “Aposentado” com desconto de 90,00
E a data atual é <DataAtual>
Quando gerar a cobrança anual
Então deve ser criada uma parcela com valor 10,00 para o
<Exercício>
Exemplos:
| DataAtual | Exercício |
| 23/10/2016 | 11/2016 |
| 23/12/2016 | 01/2017 |
30. Use valores concretos
Descreva o quê em vez de como
(sem detalhes de implementação ou interface)
Título claro e diferenciável
Uma regra por cenário
Linguagem ubíqua
Refatore!
31. Links para recursos sobre BDD e jogos:
https://bddwarriors.wordpress.com/recursos/
Contato:
anah@dbserver.com.br
BDD Warriors no
Facebook