23
Curso de Testes Automatizados Unidade II Testes Unitarios

Testes de Unidade - Unidade II

Embed Size (px)

DESCRIPTION

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

Citation preview

Page 1: Testes de Unidade - Unidade II

Curso de Testes AutomatizadosUnidade II

Testes Unitarios

Page 2: Testes de Unidade - Unidade II

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

Page 3: Testes de Unidade - Unidade II

Agenda

● Técnicas de Teste Unitários● TestNG● Mockito

Page 4: Testes de Unidade - Unidade II

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

Page 5: Testes de Unidade - Unidade II

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.

Page 6: Testes de Unidade - Unidade II

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.

Page 7: Testes de Unidade - Unidade II

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.

Page 8: Testes de Unidade - Unidade II

Interação entre testes usando objetos mocks

Como testar a chamada correta a outros objetos

Page 9: Testes de Unidade - Unidade II

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.

Page 10: Testes de Unidade - Unidade II

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.

Page 11: Testes de Unidade - Unidade II

Diferença entre mock e stubs

Page 12: Testes de Unidade - Unidade II

Diferença entre mock e stubs

Page 13: Testes de Unidade - Unidade II

Usando mock e stub juntos

Exemplo

Page 14: Testes de Unidade - Unidade II

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.

Page 15: Testes de Unidade - Unidade II

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.

Page 16: Testes de Unidade - Unidade II

Isolando mocks com os framwarks

Page 17: Testes de Unidade - Unidade II

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.

Page 18: Testes de Unidade - Unidade II

Frameworks Java

Page 19: Testes de Unidade - Unidade II

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

Page 20: Testes de Unidade - Unidade II

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");

Page 21: Testes de Unidade - Unidade II

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)

Page 22: Testes de Unidade - Unidade II

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.

Page 23: Testes de Unidade - Unidade II

Rferências

● Osherove, Roy. The art of unit testing : with examples in .NET. 2009

● Meszaros, Gerard. XUnit test patterns : refactoring test code. 2007