1. O documento discute testes de unidade, que testam componentes individuais de software para validar seu comportamento. 2. Testes de unidade testam métodos individuais e fornecem feedback rápido, documentação e validação do design. 3. Uma estrutura comum para testes de unidade envolve preparação, execução do método testado e asserções sobre os resultados.

1. Testes de unidade
Felipe Muniz | Igor Rozani

2. Apoio

3. Apoio

4. Compartilhar
#rpteccom

5. O que são testes de unidade?
• São testes de componentes individuais de um software com o
objetivo de validar se cada um deles está de acordo com o
que foi projetado.
• Em programação orientada a objetos, um teste de unidade irá
testar um e apenas um método do código de aplicação.

6. O que são testes de unidade?

7. Por que testar?
• Feedback rápido durante manutenções no sistema.
• Documentação técnica.
• Validação do design adotado no código.
• Validação de métodos isoladamente.
• Para deixar o cara da segunda palestra feliz.

8. Frameworks de teste

9. Test runners

10. Estrutura
• Os testes devem ser organizados em 3 etapas:
1. Arrange: preparação de variáveis e setup dos mocks.
2. Act: chamada ao método sendo testado.
3. Assert: verificação dos resultados obtidos em comparação ao
esperado.

11. Estrutura

12. Estrutura

13. Assert
• Verificação dos resultados obtidos em comparação ao
esperado.
• Fluxo de execução do teste é interrompido na primeira falha.
• Idealmente apenas um Assert por teste.
• Utilizar melhor tipo de Assert para o teste.

14. Assert

15. Ciclo de vida
• Preparação
o Setup antes do primeiro teste.
o Setup antes de cada teste.
• Execução
• Finalização
• TearDown depois de cada teste.
• TearDown depois do último teste.

16. Nomenclatura
• O nome do método de teste deve ser o mais expressivo
possível e é comum a utilização de nomes extensos.
Calculadora_Somar_Sucesso
Classe sendo testada
Método sendo testado
Cenário

17. Nomenclatura
• Descrever apenas o cenário:
SomarDoisNumerosComSucesso
BloquearDivisaoPorZero
• Descrever o método e o cenário:
Somar_Sucesso
Dividir_FalhaDivisorZero

18. Boas práticas
• A escrita dos testes deve seguir todas as boas práticas de
programação.
• Cada teste deve validar um cenário específico.
• Manter os testes pequenos.
• Dificuldades em implementar os testes indica que seu código
necessita de refatoração.

19. Inversão de controle (IoC)
• Desenvolvimento baseado em abstrações.
• Redução de acoplamento.
“Programe para uma interface e nunca
uma implementação”

20. Inversão de controle (IoC)

21. Inversão de controle (IoC)

22. Mock
• Objeto utilizado para substituir uma dependência e simular o
comportamento de um objeto real.
• Útil para isolar o comportamento do objeto sendo testado.

23. Mock
• Por meio da utilização dos mocks, é possível definir valores
para propriedades e comportamentos para métodos.
• Além disso, podemos verificar se determinado método ou
propriedade do mock foi chamado conforme esperado.

24. Framework de mock
MOX

25. Mock

26. Mock

27. Cobertura de testes

28. Cobertura de testes

29. Cobertura de testes
• Quantidade X Qualidade dos testes
• Cobertura 100% não é um objetivo.
• Quanto mais próximo ao Domínio da sua aplicação, mais
importante implementar testes.

30. Projetos legados
• Criar testes para as novas funcionalidades.
• Sempre que corrigir um bug, cobrir o cenário com testes.

31. Continuous Integration (CI)
• Execução automática de testes após commit e notificação em
caso de falha.
• Execução automática de testes antes de realizar pull request.
• Correção de testes é prioridade.

32. Test-Driven Development (TDD)
• Criação de testes antes do código de aplicação.
• Menor alteração(baby step) para fazer teste passar.
• Garantia de bom design para o código de aplicação.

33. Test-Driven Development (TDD)

34. Dúvidas?

35. Obrigado!
FelipeMuniz
felipemuniz09
@felipe.muniz
IgorRozani
IgorRozani
@IgorRozani
Igor RozaniFelipe Muniz