O documento aborda o Behavior Driven Development (BDD), destacando sua origem na combinação de técnicas como Test Driven Development (TDD) e Domain Driven Design. O BDD busca unificar equipes de negócios e desenvolvimento, focando em testes comportamentais e na entrega de valor do código, utilizando linguagem comum entre as equipes. Ferramentas como RSpec e Capybara são mencionadas como suporte essencial para a implementação de testes eficazes em projetos Ruby on Rails.

1. Behavior Driven
Development
UNIFICANDO PROPOSTAS DE NEGÓCIO COM TESTES E
CÓDIGO

2. Antes de tudo...
Uma introdução

3.  Engenheiro desenvolvedor Ruby
 Nascido em novembro de 89
 Graduado em Engenharia Eletrônica e
de Computação pela UFRJ
Rafael Prallon Maldonado Charruff

4. De onde veio?
 O BDD surgiu da junção das seguintes técnicas e
padrões:
 Test Driven Development
 Domain Driven Design

5. Test Driven Development
Técnica que encoraja uma aproximação evolutiva para o
desenvolvimento de sistemas ao estimular que o
desenvolvedor escreva os testes de software antes de
escrever o código da aplicação em si

6. A vantagem de criar os testes
antes
 Aumenta a confiança que o desenvolvedor tem em seu
código
 Você passa a escrever apenas o mínimo de código
necessário para que o teste passe
 Os testes passam a descrever como o sistema funciona

7. Domain Drive Design
Um conjunto de padrões para o desenvolvimento de
aplicações empresariais a partir do modelo de domínio,
visando adotar um vocabulário comum reduzindo
desentendimento entre as equipes técnicas e de
negócios.

8. Por que surgiu?
Para solucionar o problema de alguns praticantes do TDD
em focar muito em testes e negligenciando o
comportamento do mesmo.

9. TDD BDD
Gira em torno de testes
unitários
Gira em torno do teste
comportamental
É focado na qualidade do
código
É focado no valor gerado
pelo código
Geralmente escrito pelo
desenvolvedor
Geralmente escrito pelo
dono do produto
Exige mudança nos testes a
cada mudança na
funcionalidade do código
Mudanças na
funcionalidade do código
dificilmente exigem
mudanças nos testes
Aponta precisamente onde
a falha ocorre
Aponta que há falha. Não
necessariamente aonde

10. Objetivo do BDD
 Visa unificar os esforços das equipes de negócios com as equipes
de desenvolvimento, focando em minimizar os obstáculos entre
especificação, design, implementação e confirmação
 Conta com o uso vocabulário específico e simples para garantir
que todas as equipes usem a mesma lingua

11. Por que aprender ou adotar?
 Adoção em massa das práticas de BDD por parte das
grandes empresas de desenvolvimento
 As práticas de BDD e TDD fazem parte das lista de boas
práticas apoiadas pela comunidade de Ruby on Rails
 Permite que a equipe de desenvolvimento foque na entrega
de valor do código

12. Princípios básicos do BDD
 “It’s all behavior”
 “Where’s the business value”
 “Enough is enough”

13. Ferramentas

14. Ferramenta de testes focado em testes de aceitação
que permite criar especificações executáveis usando
uma linguagem próxima da natural.

15. RSPEC
Framework de testes unitários para Ruby que se diferencia
dos outros frameworks de teste por se focar no
comportamento da aplicação, ao invés de se focar em
como ele funciona.

16. Capybara
 Ferramenta que permite a realização de testes
simulando a interação do usuário com a aplicação
 Já vem instalado por padrão na versão atual do Ruby
on Rails (v5.1.2)

17. Referências
 BDDWiki: http://behaviourdriven.org
 Rspec: https://relishapp.com/rspec/
 Cucumber: https://cucumber.io
 Capybara: http://teamcapybara.github.io/capybara/

18. Contatos
 https://github.com/RafaelPrallon
 https://www.linkedin.com/in/rafaelprallon
 rafaelprallon@gmail.com