Testes de Unidade - Unidade II

1.249 visualizações

Publicada em

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

0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.249
No SlideShare
0
A partir de incorporações
0
Número de incorporações
12
Ações
Compartilhamentos
0
Downloads
33
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Testes de Unidade - Unidade II

  1. 1. Curso de Testes Automatizados Unidade II Testes Unitarios
  2. 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. 3. Agenda ● Técnicas de Teste Unitários ● TestNG ● Mockito
  4. 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. 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. 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. 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. 8. Interação entre testes usando objetos mocks Como testar a chamada correta a outros objetos
  9. 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. 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. 11. Diferença entre mock e stubs
  12. 12. Diferença entre mock e stubs
  13. 13. Usando mock e stub juntos Exemplo
  14. 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. 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. 16. Isolando mocks com os framwarks
  17. 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. 18. Frameworks Java
  19. 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. 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. 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. 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. 23. Rferências ● Osherove, Roy. The art of unit testing : with examples in .NET. 2009 ● Meszaros, Gerard. XUnit test patterns : refactoring test code. 2007

×