1. DOJO: Desenvolvimento Orientado a Objetos Dirigido por Comportamento e Teste
PROF. ME. FABIO GOMES ROCHA

2. Quem sou eu?
Professor da Unit a 5 anos
+23 anos de experiência (mercado) e 22 como professor
Scrum Master e Scrum Master Professional – Scrum Alliance
Certificado Exin ISO 27001 Foundation
Membro da Scrum Alliance a 6 anos
Mestre em Ciências da Computação - UFS
Líder do GPITIC
Líder do Agile Sergipe
Doutorando em educação Unit

4. O que é TDD?
TDD (Test Driven Development – Desenvolvimento Guiado por testes)
O desenvolvimento orientado a testes ou guiado por testes foi proposto,
inicialmente, por Kent Beck como parte da metodologia XP (Extreme Programming)
(Pedroso in Prikladnicki, Willi, Milani; 2014) e tem como objetivo código limpo e que
funcione (Beck, 2010). Conforme Back “se testar é bom, todos vão testar o tempo
inteiro (testes de unidade), até mesmo os clientes (testes funcionais)”(p. 10, 2008).
Conforme Lopes “[...]TDD é uma forma de testar meu software antes de tê-lo pronto
e não apenas criar testes. Com TDD validamos não somente se há um erro de lógica
no código e sim se os requisitos estão bem definidos para que possamos entregar
aquilo que é esperado”(p. 63, 2012).
Conforme Freeman e Price(2012, p. 5) “ Você não tem nada a perder, a não ser os
seus bugs”

5. O que é TDD?
TDD (Test Driven Development – Desenvolvimento Guiado por testes)
Conforme Mike Cohn o TDD é uma prática inestimável, isso por que ele farante que
nenhum código não testado entre no sistema. Assim, pode-se considerar que o TDD é
uma prática de projeto e de programação.(Cohn, 2011).
A Microsoft produziu dois estudos e descobriu que o numero de erros encontrados
diminui entre 20% a 38% com o uso do TDD(Sanchez, Williams e Maximilien, 2007)

6. CICLO TDD
O ciclo do TDD é: Escrever um teste, escrever
algum código para fazê-lo funcionar, refatorar o
código para que seja tão simples quanto uma
implementação dos recursos testados, repita.
(FREEMAN, PRICE, p. 6, 2012)

7. Conceitos fundamentais para TDD
Teste automático: a automação de teste é uma característica fundamental para a prática. Além de
que os testes devem ser pequenos, concisos, independentes e rápidos;
Regressão: este é um dos aspectos mais importantes de automatizar testes pois permite um reteste
após mudanças no sistema;
Cobertura: medir a quantidade de códigos com teste;
Refatorar: processo de melhoria de um sistema, sem que este perca a funcionalidade, ou seja,
mudamos a estrutura, porém sem que se altere o comportamento;
Design, não teste: os testes automatizados são mais efetivos do que os manuais, na verificação de
unidades de códigos, visando assim garantir a qualidade do sistema. Porém no TDD os testes
funcionam mais como foco de melhoria e design do sistema, auxiliando assim para o processo de
concepção do design da solução.
Predroso, 2012.

8. Ciclo TDD
1. Criar o teste;
2. Executar todos os possíveis testes e ver a aplicação falhar;
3. Escrever a aplicação para os testes passarem;
4. Re-executar todos os possíveis testes e ver se todos estão passando;
5. Refatorar;
6. Executar os testes novamente, garantindo que eles continuem passando.

9. Junit: Introdução a ferramenta
Os Xunit´s são frameworks que permitem o teste unitário, o Junit é um destes frameworks. Este
framework basicamente emprega a reflexão para caminhar pela estrutura das classes e
encontrar uma que represente um teste (FREEMAN, PRYCE, 2012), um teste Junit invoca o
objeto sob teste e depois faz uma asserção sobre os resultados usando métodos de asserção
definidos pelo Junit, os quais geram mensagens de erro úteis quando eles falham.
◦ @Teste  Identifica que a função é de teste
◦ SetUp()  Roda antes do teste;
◦ tearDown()  roda depois do teste;
◦ assertTrue()  Verifica se é verdadeiro
◦ assertEquals()  Verifica igualdade
◦ assertSame()  Verifica se os objetos são iguais

10. Contexto do primeiro teste
Entenda o
problema
Rascunhe o
projeto
(Arquitetura)
Automatize:
*monte,
*Distribua,
*Teste de
ponta a
ponta
Escreva um
teste de
aceitação
falho
Escreva um
teste de
unidade
falho
Torne o teste
bem-
sucedido
Refatore

11. BDD
“O desenvolvimento guiado por comportamento é o
desenvolvimento guiado por testes feito corretamente”
O BDD foi criado por Dan North, aproximadamente nos anos de 2003
não como uma nova metodologia, mas sim, uma forma de integrar o
TDD no desenvolvimento de software integrando-se as regras de
negócio.
https://dannorth.net/introducing-bdd/

12. Ciclo BDD

13. BDD
O BDD é um conjunto de práticas de engenharia de software que visa ajudar equipes a criar e
entregar software de valor e com qualidade com maior rapidez, para tanto o BDD emprega
questionamentos sobre o comportamento de uma aplicação antes e durante o
desenvolvimento. Assim, o BDD baseia-se em práticas ágeis e enxutas, incluindo, em particular,
o Desenvolvimento Orientado a Testes (TDD) e o Design Dirigido por Domínio (DDD, Domain-
Driven Design). Porém, o mais importante é que o BDD fornece uma linguagem comum baseada
em sentenças simples e estruturadas expressas em inglês (ou no idioma nativo dos interessados)
que facilitam a comunicação entre os membros da equipe do projeto e os participantes do
negócio.

14. BDD
Em BDD os documentos de requisitos são as histórias de usuário. As histórias de
usuários se concentram no comportamento desejável, assim, ao invés de
preocupar-se com a implementação, analisamos o comportamento desejado,
reduzindo assim mal-entendido entre os stakeholders.
Uma história de usuário deve ser testável, ser pequena o suficiente para ser
implementada em uma iteração e possuir valor para o negócio, ou seja:
especifico, mensurável, realizável, relevante e com duração fixa.

15. história de usuário
Como [função do keyuser]
Eu quero/de modo que [ o que se deseja fazer]
Para que [tarefa desejada]
Exemplo:
◦ Como um gestor de RH
◦ Eu quero calcular o INSS dos funcionários
◦ Para que eu possa emitir a folha de pagamento com seus devidos descontos

16. BDD
Assim, o BDD enfatiza o trabalho com os stakeholders para definir o comportamento do sistema
em desenvolvimento.
As histórias de usuário são artifícios que facilita a comunicação com os stakeholders na criação
de requisitos;
Cara uma das histórias de usuário ficam em cartões de forma que facilite o seu
desenvolvimento.

17. Cenário
Cada história de usuário pode ter um ou mais cenários.
Dado = Given
When = Quando
Then = Então
Ciclo: Passou, Falhou, Skypped, pending e undefined

18. Junit: Introdução a ferramenta
Dicas do Lopes(2012) para construir um bom teste:
1. Deve ser específico, objetivo e focado, ou seja, nada de um teste unitário testando coisas demais.
Alta coesão é o que você precisa alcançar;
2. Princípio básico, mas que queira repetir. Nada de um teste unitário que dependa de outro, eles são
únicos e para executar não pode depender de outro teste;
3. Refatorados. O código no teste unitário deve ser tão legível quanto seu código funcional;
4. Rápido. Ele precisa rodar muito rapidamente. Um teste unitário lento vão impactar na sua
execução, pois quanto mais lento for, menos vezes você vai executá-lo;
5. Os nomes devem ser claros e específicos, por exemplo: testeValidandoINSS();
6. Testes unitários devem ser legíveis.

19. Problema folha de
pagamento
Você esta desenvolvendo um
sistema que deve calcular os
descontos e o salário liquido do
funcionário, para tanto, temos as
seguintes regras:
Salário de
Contribuição
Alíquotas (%)
até 1.693,72 8,00
de 1.693,73 até
2.822,90
9,00
de 2.822,91 até
5.645,80
11,00

20. Problema folha de
pagamento
Você esta desenvolvendo um sistema que
deve calcular os descontos e o salário
liquido do funcionário, para tanto, temos
as seguintes regras:
Base de
cálculo
mensal em
R$
Alíquota %
Parcela a
deduzir do
imposto em
R$
De 1.903,99
até 2.826,65
7,5 142,80
De 2.826,66
até 3.751,05
15,0 354,80
De 3.751,06
até 4.664,68
22,5 636,13
Acima de
4.664,68
27,5 869,36