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

Testes de Unidade - Unidade II

  • 1.
    Curso de TestesAutomatizados Unidade II Testes Unitarios
  • 2.
    Conteúdo Pragmático ● UnidadeI ● 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 deTeste Unitários ● TestNG ● Mockito
  • 4.
    Técnicas de TesteUnitá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 testesusando objetos mocks Como testar a chamada correta a outros objetos
  • 9.
    Testes baseados noestado 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 ● Ummock 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.
  • 12.
  • 13.
    Usando mock estub juntos Exemplo
  • 14.
    Um mock porteste ● 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 escrevermock 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 comos framwarks
  • 17.
    Por que usarmosframework 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.
  • 19.
    Mockito ● É umframework 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 poucomais 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 poucomais 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 usarMockito? ● 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