O documento discute a importância de testes unitários na detecção de bugs e na evolução do código, utilizando o JUnit como ferramenta principal. Aborda a criação de testes, a relevância de casos negativos, o uso de data builders e mocks para simplificar a estrutura dos testes sem comprometer a eficiência. O autor, Renan Uchôa, é estudante de engenharia de software e desenvolvedor Java.

1. Experience
Construindo testes unitários usando JUnit 4

2. Problemas com bugs?

3. Testes unitários podem rastreá-los!!!

4. O JUnit se preocupa em monitorar
comportamentos do código

5. Quando um teste falha,…

6. é sinal de que precisamos evoluir o código

7. Geralmente começamos com testes “felizes”…

8. como por exemplo comparar o resultado de um
comportamento com um valor esperado…,

9. e torcer pra que tudo dê certo!!!

10. Testes bem construídos garantem uma
evolução segura do software

11. Comportamentos estranhos inseridos no código
serão rapidamente identificados

12. Os casos negativos também são importantes!!!

13. O importante é tentar
identificar o máximo de
cenários possíveis, e
representar isso através
de testes unitários.

14. Não vamos esquecer das Exceptions…

15. É importante criar testes que verifiquem a
ocorrência de exceções…

16. pois se o teste quebrar, temos como mapear
a origem do problema.

17. À medida que vamos
evoluindo o código, os
testes começam a ficar
um pouco mais
volumosos.

18. Imagine um teste que
cadastra 5 usuários
para verificar se eles
estão sendo persistidos. Que trabalhera!!!

19. Já ouviu falar em Data Builders?
alguns conhecem
como Fixture...
Design Pattern
responsável por
construir objetos
de maneira rápida e
descritiva

20. O código de antes...
E agora cadastrando 5 usuários!!!

21. O código…
Mostre-me
por favor!!!

22. 1- Um objeto encapsulado
2- Um método estático
que chama a fixture
3- Um método que retorna
o objeto construído
4- Métodos adicionais que 'setam'
os atributos no meio do caminho
5- A corrente só termina quando retorna o usuario

23. Ainda dá pra emagrecer mais um pouquinho,
basta ter um pouco de fé…

24. Desse jeito fica bem mais fácil de trabalhar…
reaproveitar isso
em outros testes!!!
E o melhor é que
ainda dá pra…

25. Então chega a hora
de começar a dividir
responsabilidades…
Queremos implementar o acesso ao banco mas não queremos
que o teste se preocupe com isso…
Então vamos deixar isso com o setUp()

26. @BeforeClass
@Before
@After
@AfterClass
Implementam comportamentos para serem utilizados…
- BeforeClass: Antes de iniciar a suite de testes
- Before: Antes de executar cada teste
- After: Depois de executar cada teste
- AfterClass: Depois de finalizar a suite de testes

27. Agora temos uma camada de serviço,
que implementa comportamentos
sobre Usuario…
uma camada de acesso ao
banco de dados, que
persiste as informações…
e um código já bem
estruturado e organizado

28. Mas pare ai!!!

29. Se eu tiver que acessar o banco de dados a
cada teste que fizer, será muito demorado…

30. Isso não é teste unitário…

31. Antes de pensar na integração do sistema,
precisamos garantir suas unidades!!!

32. Mas então como é que eu faço???

33. Gambiarra???
Isso se chama Mock!!!
Não…

34. Mock Object é
um padrão de
desenvolvimento
que simula
comportamentos
de objetos
concretos de
uma aplicação ou
funcionalidade.

35. e em vez de acessar o
banco de dados, ‘mocamos’
o comportamento com uma
lista, ou simplesmente não
fazemos nada…
Substituímos o
UsuárioDao por
um Mock Object
compatível…
que sobrescreve
todos os métodos…

36. Desta maneira
garantimos
testes simples e
coesos…
E fica mais fácil de manter a qualidade!!!

37. Quem sou eu?
Renan Uchôa,
estudante de Engenharia de Software
pela Universidade Federal do Pampa,
e Desenvolvedor Java pela uMov.me
Tecnologia S.A.