1. Khomp
Behavior Driven Development
Uilian Ries

2. AGENDA
● Desafios no desenvolvimento de
SW
● E o TDD?
● O que é BDD?
● TDD e BDD
● BDD numa casca de noz
● Os três amigos
● User Stories
● Especificações do comportamento
○ Gherkin
○ Gauge
● Frameworks
● Integração contínua
● Ciladas
● Benefícios do BDD
● Desafios para implementar BDD

3. Desafios no desenvolvimento de SW
● Problemas de comunicação durante o processo de desenvolvimento
● Atingir uma linguagem comum que atenda todos os envolvidos no projeto
● Entregar uma documentação que reflita o negócio
● Validar os requisitos com precisão

4. E o TDD?
● TDD se baseia em pequenos ciclos de repetições
● Criar um Teste que inicialmente não passa (Red)
● Adicionar uma nova funcionalidade do sistema
● Fazer o Teste passar (Green)
● Refatorar o código da nova funcionalidade (Refactoring)
● Escrevemos o próximo Teste
● Feedback rápido sobre a nova funcionalidade
● Código limpo e simples para o teste passar
● Maior cobertura de código

5. O que é BDD?

6. O que é BDD?
● Exemplos
● Compreensão compartilhada
● Software que importa

7. O que é BDD?
● BDD não é sobre usar Behave, Cucumber ou Specflow
● BDD começa com colaboração, conversação e compreensão
● No BDD a comunicação vem antes da automação

8. O que é BDD?
● Colaboração
○ Uma técnica de colaboração
○ Compreensão sobre o valor de cada feature
○ Como entregar cada feature em tempo otimizado
● Construir o software certo
○ Quais features possuem o maior valor
○ Descobrir o valor por colaboração, conversação e feedback

9. O que é BDD?
● Documentação
○ A documentação faz parte do fluxo
● Automação
○ Acelerar o feedback se está criando algo certo
○ Reproduzir o mesmo cenário sempre que necessário

10. BDD e TDD
● Mesmo ciclo de desenvolvimento
● BDD tem foco em comunicação
● No BDD todos falam a mesma língua
● TDD utiliza linguagem para dev e tester
● No BDD o comportamento é mais importante do que software escrito

11. BDD e TDD
● ATDD (Acceptance Test Driven Development)
○ Encoraja toda a equipe a definir os critérios de aceitação de um
software antes de começar seu desenvolvimento
○ Geralmente envolve o estabelecimento dos critérios em primeiro lugar
○ Os testes de aceitação são desenvolvidos e executados para ver os
resultados da falha com o código certo com base em exemplos.

12. ATDD (Acceptance Test Driven Development)

13. BDD numa casca de noz

14. BDD numa casca de noz
● Processo de desenvolvimento tradicional
○ Existem muitas oportunidades para perda de informação
○ Risco de compreensão equivocada
○ Falta de clareza na descrição

15. BDD numa casca de noz

16. BDD numa casca de noz
● Processo de desenvolvimento BDD
○ As especificações são elaboradas colaborativamente
○ As especificações utilizam uma linguagem comum (ubíqua)
○ A execução das especificações resultam em rápido feedback

17. Os três amigos
● 3 membros de times
○ desenvolvedor
○ testador
○ PO ou analista de negócios
● Juntos discutem features e desenham exemplos
● O testador possui grande atenção em casos esquecidos por outro membros
● O desenvolvedor aponta considerações técnicas
● O PO julga a relevância e valor de cada cenário

18. User Stories
● São partes do comportamento desejado de um sistema de software
● Amplamente utilizados em dividir funcionalidade para fins de planejamento
● Encoraja um estilo mais informal e conversacional de exigências
● Pode ser escrita em um único cartão de nota
● Critério de aceitação ajudam a validar uma user story
● Uma maneira comum de formular é a "Como ... Eu quero ... Para, ...".
● A frase "Como" refere-se a quem quer a história
● "Eu quero" descreve o que é a funcionalidade
● "para que" descreva por que eles querem essa funcionalidade

19. User Stories
● Exemplo vending machine
Consulta de itens disponíveis na máquina pelo browser
Como um cliente, eu gostaria de consultar
os itens disponíveis na máquina pelo browser,
para decidir qual o produto que irei comprar
antecipadamente.
Critério de aceitação
- Precisa suportar IE 8

20. User Stories
● Exemplo vending machine
Investigar estado da máquina pelo browser
Como um técnico, eu gostaria de consultar
o estado de cada sensor pelo browser,
para definir quais os reparos serão necessários.
Critério de aceitação
- Precisa apresentar log de erro do sensor

21. User Stories
● Ponto de entrada para obter uma linguagem ubíqua
● Base para os 3 amigos poderem descrever os cenários
● Importante para o QA desenvolver seu trabalho

22. Especificações do comportamento
● Para poder testar users stories cenários precisam ser definidos
● Para poder definir os cenários, detalhes serão necessários
● Cenários são definidos em contexto, ações e verificação

23. Especificações do comportamento
● Linguagens e ferramentas para verificar o comportamento
○ Gherkin
○ Gauge

24. Gherkin
https://github.com/cucumber/cucumber/wiki/Gherkin
● É um idioma legível para o negócio e específico do domínio
● Permite descrever o comportamento sem detalhar a implementação
● Possui dois propósitos: documentação e automatização de testes
● Pode ser utilizado Given-When-Then para descrição de passos

25. Gherkin
https://github.com/cucumber/cucumber/wiki/Given-When-Then
● Given When Then
○ Given, coloca o sistema em um estado conhecido
○ When, descreve a ação executada
○ Then, observa os resultados

26. Gherkin - Exemplo vending machine
Feature: Diagnosticar sensores pelo browser
Como um técnico, eu gostaria de consultar o estado de cada sensor
pelo browser, para definir quais os reparos serão necessários.
Scenario: Diagnosticar sensor com falha
Given acesso a página de manutenção
And o termômetro apresentando falha
When eu inicio um diagnóstico de sensores pelo botão “diagnosticar”,
Then o resultado indica erro de leitura somente na temperatura

27. Gauge
https://gauge.org
● Ferramenta criada pela Thoughtworks
● Licença GPL-3
● Suporta múltiplas linguagens: Ruby, Java, C#, Python e Javascript
● Baseado em markdown
● Suporta o conceito de documentação executável

28. Gauge
https://docs.gauge.org/longstart.html
● Terminologias
○ Specifications, descrição de feature (arquivo)
○ Specification Heading, descrição de feature (título)
○ Scenarios, mesmo que no Gherkin
○ Steps, vale por Given/When/Then

29. Gauge - Exemplo vending machine
Diagnosticar sensores pelo browser
===========================
O técnico deve ser capaz de consultar o estado de cada sensor pelo browser
Diagnosticar sensor com falha
----------------------------------------
* O técnico acessa a página de diagnóstico através do browser
* Inicia um diagnóstico de sensores pelo botão “diagnosticar”
* O resultado indica erro de leitura somente na temperatura

30. Frameworks
● Cucumber
● https://cucumber.io
● Licença MIT
● Suporta Gherkin
● Inicialmente feito para Ruby, mas possui suporte para diversas linguagens,
incluindo C++, JavaScript e Lua

31. Frameworks
● Behave
● https://pythonhosted.org/behave/
● Licença MIT
● Suporta Gherkin
● Suporte para Python

32. Frameworks
● E muito mais ...
Ferramenta Linguagem Licença
pytest-bdd Python MIT
SpecFlow C# BSD-3
Lettuce Python GPL-3.0
Chai JavaScript MIT
behat PHP MIT

33. Integração Contínua
● BDD não é dependente de CI
● Contudo, acreditamos que automação e CI podem contribuir para um
melhor desenvolvimento
● Frameworks para automação de teste podem ser combinados com CI
○ Exemplo: Behave + Splinter + Gitlab
● Segunda parte desta apresentação visitará a prática neste campo

34. Ciladas
● Ciladas são anti-patterns do BDD
● Analista ou PO escreve os cenários e passa a frente
○ Desvio entre os “3 amigos”
○ Problema em descobrir o cenário
○ Não estará revisando o documento
○ Feedback poderá não ser eficiente

35. Ciladas
● O Testador escreve os cenários no final para implementar
os testes automatizados
○ Mas ele usa Behave
○ Mas é para cobrir código legado

36. Ciladas
● O desenvolvedor inventa os cenários quando o encontro
dos “3 amigos” não resulta em algo válido
○ Idealmente sessão deve resultar em exemplos concretos
○ Ou pelo menos em cenários válidos

37. Ciladas
● Os cenários são mais focados em detalhes ao invés de
valores do negócio
○ Quando “O quê” vem na frente de “Por quê?” e “Como”
○ Importante se perguntar o porquê estão escrevendo o cenário

38. Benefícios do BDD
● Redução de tempo
○ Ajuda as equipes a se concentrar em recursos alinhados com os
objetivos comerciais
○ Desenvolver o software certo diminui no número de bugs

39. Benefícios do BDD
● Mudanças mais fáceis e seguras
○ Qualquer é fácil de ser compreendida por ambos os lados
○ A documentação acompanha o software
● Entregas mais rápidas
○ Não é mais necessário escrever uma descrição de teste durante a
homologação

40. Desafios para implementar BDD
● BDD requer grande envolvimento e colaboração comercial
● BDD funciona melhor usando contexto Agile or iterativo
● BDD não funciona bem em um ambiente isolado
● Testes pobres podem levar a maiores custos de manutenção

41. REFERÊNCIAS
John Ferguso
Dan North
Agile Alliance
Martin Fowler
BDD in Action
Rodrigo Urubatan