O documento aborda a automação de testes em quatro etapas principais: conhecimentos básicos sobre testes, cobertura de testes com Emma, desenvolvimento de testes unitários com JUnit e uso de objetos dublês em testes com Mockito. A importância de testes unitários é destacada, enfatizando a necessidade de criar cenários diversos e utilizar ferramentas de cobertura para garantir a qualidade do código. Também são discutidas boas práticas na elaboração de testes, incluindo o uso de mocks e stubs para simular comportamentos de objetos durante os testes.

1. Automatizando
em quatro passos
TESTES
@helmedeiros

2. 1. Conhecimentos básicos de testes
2. Cobertura de testes com Emma
3. Desenvolvendo testes unitários com JUnit
4. Testes unitários com objetos dubles usando mockito

4. Conhecimentos básicos de testes

5. quanto
maior
estresse menor
menor
execução
de testes
Gerry Weinberg
diagrama de influência

6. valiar”
ifica “a m maior
ar sign em produção o
estresse é b
e
test

7. Top Down de aceitação...
cenários de teste... critérios
Bottom up box...
22 caixas de texto... 15 combo

8. FIZ
uma mu
dança
QUEBROU UMA PARTE QUE NÃ
DEVIA O
TEST - Teste Isolado
ISOLATED
pida; deve ser rá
1.A execuçã o dos testes
eve ignorar as demais;
2. A execução d e um teste d
Kent Beck
TDD - Desenvolvimento Guiado por Testes

9. alta éCOESÃO um módulo
a medida da força relativa de
fraco ACOPLAMENTO módulos
é o nível de interdependência entre os

10. TESTEI
meu código
O que m ais deveria
testar?
- Lista de testes
TEST LIST ue precisa im plementar;
perações que você sabe q
ista ex emplos das o erência nula;
1.Coloque na l coloque a ve rsão de conf
ar o código.
implementa das zer para limp
2 .Para todas já e você acha que terá de fa
te todas as re fatorações qu
3.Lis Kent Beck
TDD - Desenvolvimento Guiado por Testes

11. 1. Qual o conjunto de testes, que quando passarem, demonstrará que o
código que estamos confiantes que irá calcular o relatório
corretamente?
$5 + 10 CHF = $10 se a taxa é 2:1
$5 * 2 = $10
Tornar a “quantidade” privada
Efeitos colaterais em Dollar?
Arredondamento de dinheiro?
Kent Beck
TDD - Desenvolvimento Guiado por Testes

12. ESCREVI
meu código
QUANDO EU DEVO ESCREVER
MEUS TESTES?
RST - Teste primeiro
TEST FI
.Primeiro escreva os testes; ontrolado;
1 e designe c
a o código c om o escopo
2.D epois escrev
Kent Beck
TDD - Desenvolvimento Guiado por Testes

13. ESCREVI
meu teste
COMO EU FOCO A FUNCIONALI
TESTE ? DADE E NÃO NO
serção primeiro
ST - Defina a as
ASSERT FIR
ando o código estiver certo;
a a asserção q ue passará qu
1.Pr imeiro escrev pendências;
lva de baixo p ara cima as de
2.Depois reso
Kent Beck
TDD - Desenvolvimento Guiado por Testes

14. Quando eu testo definindo uma asserção primeiro, defino como
reversa a minha lógica de construção, resolvendo um problema por
vez.
De onde a resposta vem? Do socket, certamente:
Quando pronto o socket deve estar fechado e deveríamos
2
ter lido a string abc
1
Mas, antes disso, precisamos abrir o servidor:
E o socket? Nós o criamos conectando ao servidor:
3 4
Kent Beck
TDD - Desenvolvimento Guiado por Testes

15. ESCREVI
meu teste
A ORDEM DOS PARÂMETROS
IMPORTA?
TA - Dados de teste
TEST DA
stes fáceis de ler e seguir;
dados que faça m os te ença use dado s diferentes;
1.Use
etros de cham ada fizer difer
2.Quando a or dem dos parâm
Kent Beck
TDD - Desenvolvimento Guiado por Testes

16. ESCREVI
meu teste
O QUE SIGNIFICA NO SEGUNDO
PARÂMETRO O VALOR 3?
TA - Dados evidentes
EVIDENT DA
m qual o objet ivo do dado;
1.Pense e te objetivo;
constante que transpareça es
2.Defina uma vezes para cas os diferentes.
ilize a mesma constante duas
*Não ut
Kent Beck
TDD - Desenvolvimento Guiado por Testes

17. Todos os parâmetros de um método devem ser claros enquanto as
suas intenções, assim como deve ser sua utilização. Devemos SEMPRE
evidenciar o objetivo de cada valor.
Constantes com o mesmo valor são diferidas pelo nome da constante.
1
O nome da constante diferencia os significados/intenções de cada parâmetro dentro da requisição e por conseguinte as cenário de teste.
2
Caelum
FJ-16: Laboratório Java com Testes, XML

18. TDD ento guiado por testes
Desenvolvim
1 quais as soluções para o problema?
qual o primeiro cenário que desejo resolver? 2
n++
3 qual o próximo cenário?
RESOLVIDO
X

19. er um prob lema
escolh
m teste que fa lhe!
escrever u
red

20. rápido possível!
le passar o mais
fazer e
green

21. r que está bom!
fatorar até acha
depois re
yello

22. NOSSO PROBLEMA
FizzBuzz

23. 1
2
Fizz
{
4
Buzz
dada uma Fizz
lista de 1 a 100 7
múltiplos de 3 8
múltiplos de 5 Fizz
múltiplos de 3 e 5
Buzz
11
Fizz
13
14
FizzBuzz

24. Cobertura de testes com Emma

25. verage
test cocobertura de testes
é qualquer medida de abrangência relacionada a um requisito ou a
um critério de design/implementação do código, como a verificação
de casos de uso ou execução de todas as linhas de código.

26. ENCONTRAR
código não testado
verage
test co
cobertur
a de test
es
GARANTIR
X qualidade do código

27. statement coverage
se detêm ao simples registro sobre quais linhas foram executadas.
multiple conditions coverage
mede cada condição lógica no código avaliando se existem cenários não testados.

28. código
original
Instrumentação código
avaliado
multiple conditions coverage
mede cada condição lógica no código avaliando se existem cenários não testados.
execução
dos testes

29. Instrumentação
A ferramenta de cobertura modifica o código para registrar quais
expressões avaliar em qual caminho.
Esta modificação pode ser feita tanto para o código-fonte quanto para o executável que o compilador gera.
Se for feito de código-fonte, a maioria das ferramentas não alteram a fonte original, em vez disso, eles
modificam uma cópia que é então passada para o compilador de uma maneira que faz parecer que é o
original.
multiple conditions coverage
mede cada condição lógica no código avaliando se existem cenários não testados.
Após a instrumentação, você deve executar vários testes, acumulando resultados de cobertura em alguns log.

30. Códigos com condições lógicas são instrumentados, e após a execução
são apresentados logs que descrevem dentre as possíveis condições
quais não foram testadas.
Código limpo, com condições lógicas: Código testado, com diferentes logs para as condições lógicas:
1 2
multiple conditions coverage
mede cada condição lógica no código avaliando se existem cenários não testados.

31. EclEMMA para o Eclipse.
ferramenta de cobertura de código
JaCoCode cobertura de código para Java.
JaCoCo é uma biblioteca livre

32. A execução de testes e cobertura não devem ser deixado para a fase de
build e deploy, nem muito menos serem restritas as ferramentas de
continuous deployment, todo desenvolvedor deve ser capaz de
executar quantas vezes necessário antes de comitar seu código.
EclEMMA
1
2 3

33. Cada execução da bateria de testes e cobertura de seu código realizada
pelo eclipse lhe conduzirá a um novo cenário de testes. Para cada
cenário avalie o resultado esperado e crie um novo teste para
aumentar a cobertura sob o aspecto.
2
1EclEMMA Execute a bateria de testes de
cobertura apertando no nome do
O que o seu código devera fazer? método ou da classe.
Liste os cenários e em seguida as
asserções para cada um destes.
Analise o relatório e veja oque
ainda falta ser avaliado.
3

34. Scripts de execução de testes e de cobertura são abstrações menores, e
desta forma devem ser preferíveis a grandes alterações ou escolhas
estruturais. O JaCoCo e o Emma são excelentes e enxutas bibliotecas
para execução na maquina dos desenvolvedores e serviços de deploy.
1
Criar targets para executar testes
no junit, com apontamentos para
os arquivos do emma.
JaCoCo
3
2 Criar target para criação dos
reports baseados nos arquivos
gerados após a execução dos
Criar target para execução da testes.
instrumentação pelo emma.

35. A execução de testes e cobertura devem ser repetidos na fase de build
e deploy, com o apoio das ferramentas de continuous deployment,
todo membro da equipe deve saber como está a qualidade e a
confiança no código entregue com métricas acionáveis, acessíveis e
auditáveis.
JaCoCo

36. A execução de testes e cobertura devem ser repetidos na fase de build
e deploy, com o apoio das ferramentas de continuous deployment,
todo membro da equipe deve saber como está a qualidade e a
confiança no código entregue com métricas acionáveis, acessíveis e
auditáveis.
Gráficos de cobertura de testes, especificos por build,
detalhados em pacotes.
JaCoCo

37. NOSSO PROBLEMA
FizzBuzz ESTES)
(COBERTUR A DE T

38. 1
2
Fizz
{
4
Buzz
dada uma Fizz
lista de 1 a 100 7
múltiplos de 3 8
múltiplos de 5 Fizz
múltiplos de 3 e 5
Buzz
11
Fizz
13
14
FizzBuzz

39. Desenvolvendo testes unitários com JUnit

40. itário
este un re uma classe
T apenas sob
Um teste de unitário é um pedaço de código (normalmente uma
classe) que chama um outro pedaço de código e verifica a exatidão de
alguns pressupostos. Se os pressupostos estiverem errados, o teste de
unidade falha.

41. Relatório
X sucessos
teste fixture Y falhas
Z erros
teste unitário teste unitário
test case test case test case executar
teste fixture
test case test case test case
test case test case test case
test case test case test case test case test case test case
test case test case test case test runner
Suite de Teste
executar

42. JUnit
este runner
t
O JUnit é um framework open-source, criado por Erich Gamma e Kent
Beck, com suporte à criação de testes automatizados na linguagem de
programação Java.

43. A razão pela qual usamos testes em métodos ágeis é para que
tenhamos especificações executáveis, adequadas sobre o que está
sendo desenvolvido. Essas especificações devem falar sobre o que uma
unidade faz, não sobre como ele executa suas tarefas.
•assertEquals(expected, actual) •assertNotNull(Object object)
•assertEquals(String message, expected, actual) •assertNotNull(String message, Object object)
•assertSame(Object expected, Object actual) •assertTrue(String message, boolean condition)
•assertSame(String message, Object expected, Object actual) •assertTrue(boolean condition)
•assertNotSame(Object expected, Object actual) •assertFalse(String message, boolean condition)
•assertNotSame(String message, Object expected, Object actual) •assertFalse(boolean condition)
•assertNull(Object object) •fail()
•assertNull(String message, Object object) •fail(String message)

44. A elaboração dos cenários de teste envolvem a reflexão lógica, ou a
evolução na forma de sincronizar fixtures que devem ser
sincronizados tendo em mente o ciclo de execução dos testes.
@BeforeClass
@Before
TEST CASE
@After
@AfterClass
@Before @AfterClass
@BeforeClass @Ignore
@After @Test(expected=...)

45. Comumente um conjunto de testes unitários devem ser executados em
conjunto, seja devido a considerações enquanto ao raio de danos que
uma alteração possa causar ou sentido funcional. Para isso usamos as
Suites de teste.
1
Crie uma JUnit Test Suite
nomeando-a apropriadamente
3
Execute a suite de testes, e
analise o conjunto dos relatórios.
Suite de testes
2
Defina a estratégia de
agrupamento e quais são as
classes que fazem parte deste.

46. Maior parte do tempo você estará criando objetos que supram e
especifiquem suas necessidades para seus casos de teste. Quando
acontecer utilize Builders|ObjectMother como formas de especificar
apenas o necessário.
fixtures
1 2 3
Utilize os builders para tornar
Crie uma JUnit Test Suite Crie uma classe Builder para seu mais legível cada uma das
nomeando-a apropriadamente objeto. opções.

47. “Métodos estáticos dificultam a escrita de testes de unidade. Para
resolver isso podemos: evitar a escrita de métodos estáticos, ou criar
abstrações que escondem esses métodos. Nao é feio criar abstrações
como a Relogio; feio é não testar!” http://www.aniche.com.br/
1 2
encontre locais onde você utiliza Defina uma interface a ser
métodos estáticos que precisam utilizada no sistema em seu lugar
ser simulados para seus casos de
teste.
testando métodos estáticos
4
Injete o objeto com o
3
comportamento que retorne
como hoje o valor desejado
Declare o campo em sua classe e
em seguida substitua o mesmo
pelas antigas chamadas estáticas.
http://www.aniche.com.br/2011/09/testando-datas-e-metodos-estaticos/

48. Um erro sem mensagem, ou sem referencias aninhadas pode ser uma
pedra no sapato. Desta forma tratar exceções na maior parte das vezes
deve estar relacionada as mensagens retornadas, assim como o tipo de
erro.
1
encontre locais onde você utiliza
métodos estáticos que precisam
ser simulados para seus casos de
teste.
tratando exceções
2 Defina apenas a exceção
esperada no bloco try catch.
Manter throw da exceção
recebida. E adicionar assert para
mensagem.

49. NOSSO PROBLEMA
Frutas ctMother)
uilders e Obje
(JUnit, B

50. Testes unitários com objetos dubles usando mockito

51. ubmmy
Dbofake e dules
Test s, mocks, stu
Muitas vezes objetos sob teste dependem de outros objetos, sobre os
quais não temos nenhum controle (as vezes nem funcionam ainda).
Neste caso usamos os dublês de teste, quaisquer objetos falsos,
utilizado no lugar de um objeto real, com propósitos de teste.
“There is no object-oriented problem that cannot be solved by adding a layer of indirection, except, of course, too many layers of indirection.”

52. stub não quebram teste quando não chamados.
objetos que possuem respostas pré-configuradas,
mockquando não chamados.
objetos que esperam ser acionados de uma forma específica, falham

53. Muitas vezes, precisamos que nossa classe de teste se comporte de uma
determinada maneira, com pontos de verificação temporários, ou
ainda com uma implementação que não faz sentido em produção.
Durante os testes usará acesso ao filesystem ao invés de base de dados.
1 2
Devemos criar uma interface para
quando verificarmos um objeto a ser testado, ou
o mesmo e substituí-lo por sua
comportamento, apenas de estado.
stubs
auxiliar que não necessitar uma verificação de
implementação.
3
Criar uma implementação com o
comportamento desejado, e
esperado.

54. Muitas vezes precisamos verificar o comportamento de um objeto
principal ou auxiliar em uma dada funcionalidade. Para estes casos o
mais indicado é a utilização dos MOCKS.
1
mocks
quando verificarmos um objeto a ser testado, ou
auxiliar que necessitar uma verificação de
comportamento.
Devemos criar um mock para o
mesmo.
2
3 Devemos verificar o
comportamento do mesmo.

55. Mockito é um framework de mocking, que permite escrever testes
bonitos com API limpa e simples.
•Cria Mocks de classes concretas assim como interfaces;
•Anotações com syntax sugar; (@Mock)
•Verificação dos erros é simplificada;
•Suporta a verificação do exato numero assim como no mínimo um acesso de método;
•Possuí verificação ou stub simplificado e flexível com utilização de matchers
(anyObject(), anyString() ou refEq());
•Permite a criação de matchers customizados para argumentos usando hamcrest;