Técnicas de teste de unidade; TestNG; Mocks com Mockito

1. Curso de Testes Automatizados
Unidade II
Testes Unitarios

2. Conteúdo Pragmático
● Unidade I
● Introdução a teste de software
● Introdução a automação de teste de software
● Básico sobre teste unitário
● Unidade II
● Técnicas de Teste Unitários
● TestNG
● Mockito
● Unidade III
● Testando com Banco de Dados
● DBUnit
● Testes Funcionais
● Selenium
● Unidade IV
● Princípios e Filosofia de Testes Automatizados
● Introdução ao TDD

3. Agenda
● Técnicas de Teste Unitários
● TestNG
● Mockito

4. Técnicas de Teste Unitários
● Stubs e como eles nós ajudam a quebrar as
depêndencias
● Técnicas de refatoração para tornar o codigo
mais testavel
● Mocks and Stubs

5. Introdução a stubs
● Definições
● Uma dependência externa, é um objeto em seu
sistema com o qual seu código sob teste interage ,
e sobre a qual você não tem controle. (Ex.:
sistemas de arquivos, threads, memória, tempo,
etc.)
● Um stub é um substituto controlável para uma
dependência existente no sistema. Usando um
stub, você pode testar seu código sem lidar com a
dependência direta.

6. Tecnicas para quebrar
dependências
● Idetificando dependência
● Determinando como facilitar o teste
● Adicionando mais uma camada de indireção
● Refactoring do projeto para ser mais testavel
● Refactoring é o ato de mudança no design do
código sem quebrar funcionalidade existente.
● Seams são lugares em seu código onde você pode
conectar diferentes funcionalidades, atraves de
stubs.

7. Tecnicas para quebrar
dependências
● Refactoring do projeto para ser mais testavel
● Extrair uma interface para permitir a substituição de
execução subjacente.
● Injetar implementação de stub em uma classe sob
teste.
● Receber uma interface ao nível do construtor.
● Receber uma interface como uma propriedade get
ou set.
● Obter um stub pouco antes da chamada de
método.

8. Interação entre testes usando
objetos mocks
Como testar a chamada correta a outros objetos

9. Testes baseados no estado vs
Testes de interação
● Testes baseados no estado (também chamada
de verificação de estado) determina se o
método exercido funcionou corretamente,
examinando o estado do sistema em teste e
seus colaboradores (dependências) depois que
o método é executado.
● Testes de interação é testar como um objeto
envia ou recebe dados outros objetos com o
qual interage.

10. Mock Object
● Um mock object é um objeto falso no sistema
que decide se o teste de unidade passou ou
falhou. No sentido de verificar se o objeto em
teste interagiu como esperado com o objeto
falso. Há geralmente não mais do que um
mock por teste.

11. Diferença entre mock e stubs

12. Diferença entre mock e stubs

13. Usando mock e stub juntos
Exemplo

14. Um mock por teste
● Em um teste onde testamos apenas uma coisa
(que é o recomendo), não deve haver mais de
um objeto mock. Todos os outros objetos falsos
atuaram como stubs.
● Tendo mais de um teste simulado por
usualiado significa que você está testando mais
de uma coisa, e isso pode levar a com-testes
complicados ou frágil.

15. Problemas em escrever mock e
stubs manualmente
● Leva tempo para escrever o mocks e stubs.
● É difícil escrever stubs e mocks para as classes e interfaces quetem
muitos métodos, propriedades e eventos.
● Para salvar o estado de várias chamadas de um método de
simulação, você precisa escrever muito código para salvar os dados.
● Se você deseja verificar todos os parâmetros de uma chamada de
método, você precisa escrever várias acersões. Se a primeira
afirmação falhar, as outros nunca seram executadas, porque huve
uma exceção.
● É difícil a reutilização de código simulado e stub para outros testes.

16. Isolando mocks com os framwarks

17. Por que usarmos framework para
isolar os mocks
● Definição
● Um isolation framework é um conjunto de APIs
programáveis que tornam a criação de objetos
mock e stub muito mais fácil. Esses frameworks
vem para salvar o desenvolvedor da necessidade
de escrever código repetitivo para testar ou simular
interações de objeto.

18. Frameworks Java

19. Mockito
● É um framework para criação de mocks em
sistema java, disponível em http://mockiyo.org
● Sua API é bastante intuitiva e de uso simples
● Um teste com mockito envolve basicamente:
● Criação de mocks
● Configuração de stubs
● Execução do SUT
● Verificação das alterações esperadas

20. Conhecendo um pouco mais da API
● Stubing - Laçando exceção
● doThrow(new
RuntimeException()).when(mockedList).clear();
mockedList.clear();
● when(mock.someMethod("some arg"))
.thenThrow(new
RuntimeException()).thenReturn("foo");
mock.someMethod("some arg");

21. Conhecendo um pouco mais da API
● Stubing - Uso de matchers
● when(mockedList.get(anyInt())).thenReturn("elemen
t");
//print “element”
System.out.println(mockedList.get(999));
verify(mockedList).get(anyInt());
● AnyString(), any(Class)

22. Por que usar Mockito?
● A diferença do Mockito em relação aos outros
está na sua filosofia simples “stub-run-verify”,
que se diferincia do EasyMock e Jmock, que
seguem a filosofia “expect-run-verify”.Está
ultima mistura conceitos de stub com
verificação no expect. Tornando o testes
menos claro e com necessidade de um número
maior de configurações.

23. Rferências
● Osherove, Roy. The art of unit testing : with
examples in .NET. 2009
● Meszaros, Gerard. XUnit test patterns :
refactoring test code. 2007