O documento apresenta um overview sobre metodologias de desenvolvimento orientadas a testes, abordando TDD, BDD e ATDD, com foco em suas definições, benefícios e exemplos práticos. TDD, criado por Kent Beck, enfatiza a escrita de testes antes do código; BDD, proposto por Dan North, promove uma linguagem comum entre equipes técnicas e não técnicas; e ATDD, desenvolvido por Elisabeth Hendrickson, visa a colaboração na definição de requisitos. O documento também menciona a importância de boas práticas na definição de histórias de usuários e testes de aceitação.

1. Intro
Metodologias de
Desenvolvimento
Orientadas à Testes

2. Esta apresentação faz
parte de um overview que
fiz (como colaboradora da
Bravi) para a Nexxera onde
estavam presentes os
gestores, time de
desenvolvimento
desenvolvedores e
analistas de qualidade.

3. Oi!
Eu sou a Bárbara
Estou aqui porque amo Quality Assurance e aprendi a utilizar o BDD pra
pensar como o usuário pensa aos escrever os meus cenários

4. ◎ Conceitos
◉ TDD
◉ BDD
◉ ATDD
◎ Exemplos ATDD + BDD
◎ Frameworks
Agenda

5. TDD, BDD e ATDD
Todas são abordagens de Desenvolvimento
de Software orientado à Testes

6. TDD
Test Driven Development
1

7. O que é?
É uma abordagem de
desenvolvimento de
software que nasceu
dos conceitos do XP
(Extreme
Programming) em
1999, que defendia
que os testes
deveriam ser
desenvolvidos antes
do código.
Criador
Kent Beck foi quem
re-descobriu a
técnica em 2003 e a
difundiu.
TDD

9. ◎ Escrever um teste, sem mesmo ter escrito o
código real a ser testado (o que deseja testar?).
◎ Executar os testes (sem código) e acompanhar
a falha (Red)
◎ Testar novamente, agora para passar (Se não
passou algo saiu errado, faça novamente o
passo 3) (Green)
◎ Refatore sua funcionalidade e a escreva por
completo (o teste também) (Refactor)
◎ Passe para o próxima estória ou caso de uso e
inicie novo teste.
TDD

10. BDD
Behavior Driven Development
2

11. O que é?
É uma abordagem
que funciona muito
bem com uma
metodologia ágil,
encoraja devs, qas, e
pessoas não técnicas
e de negócios a
utilizarem uma
linguagem única
facilitando a
conversação.
Criador
Dan North, em 2003,
concebeu em reposta
ao TDD, ele retira a
palavra “teste” do
nome da técnica e a
traz de volta ao
comportamento da
aplicação.
BDD

13. ATDD
Acceptance Testing Driven
Development
3

14. O que é?
É uma abordagem
para a criação de
requisitos de forma
colaborativa entre o
cliente e a equipe. É
descrita de forma
natural para que
todos entendam o
que será entregue
sem criação de
doctos adicionais.
Criador
Elisabeth
Hendrickson, em
2008, criou a técnica
se baseando em
conceitos de BDD,
TDD e Especificação
por exemplos.
ATDD

16. Exemplos
ATDD + BDD

17. Estória (User Story)
Como um usuário do site
JetBlue
Eu gostaria de encontrar
vôos de ida e volta para a
cidade de destino
Para que eu agende a
minha viagem de férias
“As a/an …
I would like ..
So that”
Cenário (Scenario)
Dado que eu acesso o site da JetBlue
Quando escolho cidade de origem
E escolho data de saída
E escolho cidade de destino
E escolho data de retorno
Então eu visualizo uma lista de vôos
relacionados à pesquisa
“ Given …
When …
Then … ”
Exemplo

18. INVEST
◎ Independente: a estória precisa ser compreendida sozinha e sem
dependência de outra história
◎ Negociável: a estória precisa captar a essência e não detalhes. Com o
tempo, essa história poderá ser detalhada, incluindo-se testes de
aceitação, novas ideias, etc.
◎ Valiosa: a estória do usuário precisa entregar valor ao usuário, se não
tiver, não deve ser implementada.
◎ Estimável: uma boa estória precisa ser estimável quanto a sua
complexidade. Se estiver difícil de estimar, essa história precisa ser
quebrada em histórias menores.
◎ Tamanho apropriado: uma estória deve ser implementada em no
máximo 1 Sprint. Se isso não for possível, a história deve ser
quebrada em histórias menores.
◎ Testável: uma história de estória precisa ser clara o suficiente para
que possa ser validado se o resultado obtido está de acordo com o
que foi definido na história.

19. ◎ Escreva menos, converse mais
◎ Regras de negócio mais que regras de
sistema
◎ Faça com o time (com o objetivo de
disseminação de conhecimento)
◎ Otimize a velocidade da entrega de
valor ao cliente
◎ Critérios de aceitação devem ser
flexíveis
Dicas

20. Cenário Outline: Busca por vôos inválidos
Quando eu escolho a <cidade_origem>
E escolho a <data_saida>
E escolho a <cidade_destino>
E escolho a <data_retorno>
E eu busco por vôos
Então eu vejo amesagem de erro “Vôo não encontrado”
Exemplos:
| cidade_origem | data_saida | cidade_destino | data_retorno |
| "Florianópolis" | "02/01/2018" | "São Paulo" | "28/01/2018" |
| "Miami" | "02/01/2018" | "Cairo" | "28/01/2052" |
Exemplos

21. Unitários
Componente
Integração
Aceitação
Pirâmide de Testes

22. 1. Robot Framework, keyword-drive approach for accept tests
2. Selenium, base to the most of accept tests frameworks
3. Concordion, Specification by example (SbE) framework
a. Concordion.NET, acceptance testing in .NET
4. FitNesse, a fork of Fit
5. Cucumber, a BDD acceptance test framework
a. Capybara, acceptance test framework for Ruby
b. Watir, acceptance test framework for Ruby
c. Behat, BDD acceptance framework for PHP
d. Lettuce, BDD acceptance framework for Python
6. CucumberJS
a. Mocha, a popular accept test framework based on
Javascript and Node.js
b. Protractor, a popular accept test framework for
Angular Applications based on Javascript and Node.js
Frameworks

24. “
Mão na massa! =D
◎ Exemplo ContaAzul com Cucumber + Capybara
(Ruby)
◎ Exemplo JetBlue com o CucumberJS + Protractor
(Javascript + NodeJS)

25. Obrigada!
Vamos conversar?
Você pode me encontrar
twitter @barbarapcabral & email barbaracabral@gmail.com