SlideShare uma empresa Scribd logo
Testes de Unidade com Junit
Palestra Café com Tapioca:
      Testes de Unidade com Junit




Instrutor: Fabrício Lemos           15/12/2007
Agenda
●   Conceito de Testes de Unidade
●   Junit
●   EasyMock
●   DbUnit
●   Desenvolvimento Guiado por Testes - TDD
Testes de Software
●   É um tópico importante e vital no
    desenvolvimento de software
●   Todo mundo sabe que testes precisam ser feitos
●   Existe uma quantidade enorme de aspectos que
    precisam ser testados em um sistema
Testes de Software
●   O sistema deve passar por diversos tipos de teste
    antes de entrar em produção
    –   Unidade
    –   Integração
    –   Funcional
    –   Stress e performance
    –   Aceitação
Testes de Software
●   É praticamente impossível evitar que erros sejam
    inseridos no código
    –   Atividade complexa
    –   Manipula uma grande quantidade de elementos
        abstratos
    –   Inclusões de novas funcionalidades podem influenciar
        nas já existentes
    –   Muitas vezes é difícil ter certeza que o código está
        totalmente correto até que ele seja executado
    –   Geralmente os desenvolvedores do projeto possuem
        diferentes níveis de habilidades
Testes de Software
●   Mesmo tendo reconhecida importância no
    desenvolvimento de software, os teste costumam
    ser vistos como uma atividade chata e repetitiva
    –   Só costumam receber atenção quando os problemas
        começam a ser tornar comuns
         ●   Geralmente só são iniciados quando o produto está todo
             “pronto”
Testes de Software
●   Muitos projetos assumem que o código
    desenvolvido está livre de erros e postergam os
    testes para as fases finais do desenvolvimento
    –   Preferem remediar do que prevenir
    –   “Está tudo pronto, só falta testar”
Testando o Código da Aplicação
●   Como ter certeza de que o código escrito faz o
    que deveria fazer e não contém erros?
●   Abordagens comumente usadas
    –   Escreve-se um método main que chama o método
        escrito e verifica-se o retorno
    –   Espera-se que a funcionalidade esteja pronta e realiza-
        se um teste funcional manual
●   Os testes são feitos de maneira pontual
    –   Não é possível a realização de testes de regressão
Testando o Código da Aplicação
●   Testes não são automatizados
    –   Não é possível utiliza-los na integração contínua
●   Não são gerados relatórios sobre a execução dos
    testes
●   Testes não são executados de maneira isolada
    –   Maior dificuldade em encontrar a fonte de um erro
●   Não há disciplina para a realização dos testes
Testes de Unidade
●   Examinam o comportamento de uma “unidade de
    trabalho” distinta
    –   Em java, geralmente representada por um único
        método
●   Unidades de trabalho são testadas de maneira
    isolada
●   Possuem natureza diferente dos testes de
    integração e de aceitação
    –   examinam como vários componentes interagem
Objetivos
●   Verificar se um pedaço de código faz o que o
    desenvolvedor acha que ele faz
●   Verificar se um pedaço de código SEMPRE faz o
    que o desenvolvedor acha que ele faz
●   Identificar bugs prematuramente
●   Permitir que novas funcionalidades sejam
    adicionadas sem comprometer as já existentes
●   Diminuir o impacto das refatorações de código
Vantagens dos Testes de Unidade
●   Permite uma grande cobertura dos testes
●   Pode facilmente simular condições de erro
●   Melhora o trabalho em equipe
    ●   Permite ao desenvolvedor entregar código de
        qualidade (testado) sem esperar que outras partes
        estejam prontas
●   Dá-lhe a confiança que seu código funciona
    ●   “Alguém” assistindo a alteração/inclusão de novas
        funcionalidades
Vantagens
●   Diminui o tempo gasto com depuração de código
    ●   Quando há algum erro, te diz o método que falhou e o
        motivo da falha
●   Melhora a implementação
    ●   Testes de unidade são os primeiros “clientes” do
        código
●   Serve como uma documentação do código
    ●   Aprendizagem por exemplos
Vantagens
●   São facilmente incorporados na Integração
    Contínua
●   Relatórios sobre a corretude do código e a
    cobertura dos testes são gerados de maneira
    automática
Junit
●   Framework de teste criado por Erich Gamma e
    Kent Beck
●   Possui uma api bastante fácil e simples
●   Rapidamente se tornou o framework padrão para
    testes em Java
●   Possui suporte para diversas ferramentas: Eclipse,
    Maven, Ant, etc....
Junit
●   Foram desenvolvidas diversas extensões para
    facilitar os testes de partes específicas de um
    projeto
    –   EasyMock
    –   DbUnit
    –   StrutsTestCase
    –   Cactus
    –   Shale Test Framework
    –   etc...
Escrevendo os Testes

public class Calculadora {

    public int somar(int op1, int op2) {
      return op1 + op2;
    }

}
Escrevendo os Testes
import static org.junit.Assert.*;
import org.junit.Test;

public class TestCalculadora {

    @Test
    public void testSomar() {

        Calculadora calc = new Calculadora();
        int resultado = calc.somar(2, 3);

        assertEquals(5, resultado);
    }
}
Testes de Unidade com Junit
Se o método passar no teste...
Se o método não passar no teste...
Outros Asserts
void assertEquals(Object expected, Object actual)

void assertTrue(boolean condition)

void assertFalse(boolean condition)

void fail()

void assertArrayEquals(Object[] expecteds, Object[] actuals)

void assertNull(Object object)

void assertNotNull(Object object)

void assertEquals(String message, Object expected, Object
   actual)
Boas Práticas
●   Cada classe do sistema deve ter sua própria classe
    testadora
●   Cada método do sistema deve ter seu próprio
    método testador
●   O nome das classes testadoras devem seguir o
    padrão TestNomeClasseTestada
    –   Não prejudica o code completion
    –   Classes reconhecidas automaticamente pelo Maven
Boas Práticas
●   Pacote da classe testadora deve ser o mesmo da
    classe testada
    –   Permite o teste de métodos protected
●   Classes testadoras devem ser armazenadas em
    pastas separadas
    –   Facilita o empacotamento da aplicação
    –   src/test/java
         ●   Padrão do Maven
Classe Usuario

public class Usuario {

    private String nome;

    private Integer idade;

    //get e set...

}
Validação de um Usuário

public boolean validarUsuario(Usuario usr) {

if (usr.getIdade() > 0 &&
       usr.getNome().length() > 2) {

      return true;
}
    return false;
}
Testando a Validação
@Test
public void testValidarUsuario() {

    Usuario usuario = new Usuario();
    usuario.setIdade(18);
    usuario.setNome("Cejug");

    boolean resultado = new
      UsuarioManager().validarUsuario(usuario);

    assertTrue(resultado);
}
Testando a Validação
@Test
public void testValidarInvalido() {

    Usuario usuario = new Usuario();
    usuario.setIdade(18);
    usuario.setNome("");

    boolean resultado = new
      UsuarioManager().validarUsuario(usuario);

    assertFalse(resultado);
}
Isolando os Métodos Testados
●   A maioria dos métodos de um sistema possui
    dependências externas à classe
●   Umas das principais características dos testes de
    unidade é o isolamento das unidades testadas
    –   Permite facilmente identificar o local do erro
         ●   Diminui o tempo de debug
    –   As dependências não precisam estar prontas para que
        o método seja testado
●   Para isolar os métodos testados, as dependências
    devem ser substituídas por dependências “falsas”
Método com Dependência

public void inserirUsuario(Usuario usuario) {

    usuario.setDataCadastro(new Date());

    if(validarUsuario(usuario)){
      usuarioDAO.inserirUsuario(usuario);
    } else {
      throw new IllegalArgumentException();
    }
}
Objetos Mock
●   Na realização dos testes (em tempo de execução),
    as dependências são substituídas por objetos
    Mock
    –   Injeção de dependência
●   Simulam as dependências dos métodos testados
●   São objetos “vazios”
    –   Não contém nenhuma lógica
●   Podem ser feitos pelo próprio desenvolvedor ou a
    partir de alguma biblioteca
EasyMock
●   Biblioteca para geração dinâmica de Mocks
●   Gera objetos mock que implementam qualquer
    interface da aplicação
    –   Possui uma extensão para geração de mocks para
        classes
EasyMock
●   Permite verificar se o método testado colaborou
    corretamente com a dependência
    –   Permite a configuração dos objetos mock
         ●   Quais os argumentos que o mock deve receber do método
             testado
         ●   Qual deve ser o retorno do método chamado
         ●   Se a chamada deve lançar alguma exceção
●   Facilidade para simular condições de erro
Utilizando Mocks
1.Criar o mock da interface a ser simulada
2.Configurar o comportamento do mock
3.Fazer com que a unidade testada utilize o objeto
  mock ao invés da dependência original
  1.Injetar o Mock
4.Chamar a unidade a ser testada
5.Verificar o valor retornado
6.Verificar se a unidade testada colaborou
  corretamente com o mock
Utilizando Mocks


// 1. criando o mock
UsuarioDAO mock =
  EasyMock.createMock(UsuarioDAO.class);
Utilizando Mocks

// 2. configurando o comportamento do
// mock
Usuario usuario = new Usuario();
usuario.setIdade(25);
usuario.setNome("Café com Tapioca");

mock.inserirUsuario(usuario);
EasyMock.replay(mock);
Utilizando Mocks

// 3. Injetando o Mock
UsuarioManager manager =
  new UsuarioManager();

manager.setUsuarioDAO(mock);

// 4. chamando o método a ser
// testado
manager.inserirUsuario(usuario);
Utilizando Mocks

// 5. Verificando o comportamento do
// método
assertNotNull(usuario.getDataCadastro());

// 6. Verificando se o método
// usuarioDao.inserir() foi chamado com o
// usuário passado
EasyMock.verify(mock);
Mocks – Boas Práticas
●   Sempre utilize injeção de dependências em suas
    classes
●   Acesse as dependências através de suas Interfaces
    e não através da implementação
●   Tenha bem definido qual o comportamento de
    seus métodos nas interações com as dependências
Testando a Camada de Persistência
●   Como ter certeza de que seu código de acesso a
    dados está lendo e escrevendo corretamente na
    base de dados?
●   É necessária uma integração com o banco de
    dados na realização dos testes
    –   Misto entre teste de unidade e teste de integração
●   Quando feita de forma não automática, a
    verificação depende da inspeção visual do
    conteúdo da base de dados
Testando a Camada de Persistência
●   Para automatizar os testes duas condições tem
    que ser satisfeitas
    –   O conteúdo da base de dados tem ser conhecido no
        início de cada teste
    –   Deve ser possível verificar o conteúdo da base de
        dados após cada teste
●   Os testes ainda devem ser realizados
    independentemente
    –   Testar a inserção independentemente da seleção
DbUnit
●   Extensão do Junit especializada em testes
    integrados ao banco de dados
●   Permite o controle do conteúdo armazenado na
    base de dados
    –   Exporta dados para a base através de arquivos XML
●   Possui métodos de verificação do estado da base
    de dados
    –   Importa dados da base e compara com arquivos XML
Testando com o DbUnit
  ●   O conteúdo da base de dados é configurado
      através de DataSet no formato XML
  ●   Por default, antes de cada teste a base de dados é
      esvaziada e re-populada com o conteúdo do
      DataSet
<dataset>
   <Usuario codigo="-1" nome="josefino" idade="20" />
   <Usuario codigo="-2" nome="maria" idade="40" />
   <Usuario codigo="-3" nome="jose" idade="40" />
</dataset>
Testando com o DbUnit
●   Classe de teste deve herdar de DatabaseTestCase
●   Implementar os métodos
    –   IDatabaseConnection getConnection()
         ●   Retorna uma conexão com a base de dados
    –   IDataSet getDataSet()
         ●   Retorna o DataSet para o povoamento da base de dados
Testando com o DbUnit
protected IDatabaseConnection getConnection()
  throws ClassNotFoundException,
         SQLException {

    Class.forName("org.hsqldb.jdbcDriver");
    Connection jdbcConnection =
      DriverManager.getConnection(
      "jdbc:hsqldb:sample", "sa", "");

    return new
           DatabaseConnection(jdbcConnection);
}
Testando com o DbUnit

protected IDataSet getDataSet() throws
  DataSetException, IOException {

    FileInputStream fileIS = new
      FileInputStream("dataset.xml");
    return new FlatXmlDataSet(fileIS);
}
Testando a Seleção de Usuários

public interface UsuarioDAO {

    List<Usuario> selecionarUsuarios(
      String  nome);

}
Realizando o Teste
●   Montar o(s) parâmetro(s) para a busca
●   Criar o retorno esperado de acordo com o
    DataSet de povoamento da base de dados
●   Realizar a busca
●   Verificar se o resultado da busca é igual ao
    resultado esperado
@Test
public void testSelecionarUsuarios() {

    String parametroBusca = "jose";

    List<Usuario> esperado = new
      ArrayList<Usuario>();
    esperado.add(new Usuario(-3L));
    esperado.add(new Usuario(-1L));

    List<Usuario> retorno usuarioDAO.
      selecionarUsuarios(parametroBusca);

    assertEquals(esperado, retorno);
}
Desenvolvimento Guiado por Testes
            (TDD)
●   A escrita de testes ajuda na melhoria do design do
    código
●   Ao se perceber os benefícios dos testes, a
    tendência é escreve-los o quanto antes
●   Com o alcance da maturidade, durante a
    implementação de um método o desenvolvedor já
    imagina como irá testa-lo
TDD
●   Quanto mais cedo os testes são implementados,
    maiores são os benefícios
    –   Evita que bugs se espalhem pela aplicação e os
        tornam mais fáceis de ser corrigidos
●   Os adeptos do TDD levam essa prática ao
    estremo
    –   Os testes são escritos antes do código a ser testado
TDD
●   A regra básica do TDD é somente escrever
    código se existir algum teste falhando
    –   Regra válida para implementação de novas
        funcionalidades ou para correção de bugs
●   Somente o código estritamente necessário para
    fazer o teste passar deve ser escrito
    –   Refatorações são permitidas
Codificando com TDD
●   Escreva o teste para a funcionalidade desejada
    –   O teste irá falhar
●   Escreva o código necessário e suficiente para o
    teste passar
●   Refatore o código
    –   Elimine possíveis duplicações de código
●   Repita os passos quantas vezes necessário
●   Entregue o código
Vantagens do TDD
●   Antes mesmo de começar a implementar o
    método, o desenvolvedor já tem definido qual
    será seu comportamento
●   O código já nasce sem vícios de design
●   Evita que bugs sejam adicionados ao código
Vantagens do TDD
●   Mantém o desenvolvedor focado no problema a
    ser resolvido
    –   Código é o mais simples que funciona
         ●   Não procura antecipar mudanças
    –   Manutenção é garantida pela não duplicidade e pela
        simplicidade do código
Duvidas???
          ●   Contato
    –fabricio.lemos@gmail.com
–   discussao@cejug.dev.java.net
Referências
●   http://www.junit.org/
●   http://www.easymock.org/
●   http://dbunit.sourceforge.net/
●   JUnit in Action
    –   Vincent Massol
●   JUnit Recipes: Practical Methods for Programmer
    Testing
    –   J. B. Rainsberger
●   Extreme Programming
    –   Vinicius Manhaes Teles

Mais conteúdo relacionado

Mais procurados

Apresentacao Testes de Unidade
Apresentacao Testes de UnidadeApresentacao Testes de Unidade
Apresentacao Testes de Unidade
Aline Ferreira
 
Introdução a testes unitários com jUnit
Introdução a testes unitários com jUnitIntrodução a testes unitários com jUnit
Introdução a testes unitários com jUnit
Leonardo Soares
 
Testes de Unidade com JUnit
Testes de Unidade com JUnitTestes de Unidade com JUnit
Testes de Unidade com JUnit
elliando dias
 
Java 12
Java 12Java 12
Testes Unitários/Integrados
Testes Unitários/IntegradosTestes Unitários/Integrados
Testes Unitários/Integrados
Giovanni Bassi
 
Qualidade no desenvolvimento de Software com TDD e PHPUnit
Qualidade no desenvolvimento de Software com TDD e PHPUnitQualidade no desenvolvimento de Software com TDD e PHPUnit
Qualidade no desenvolvimento de Software com TDD e PHPUnit
Domingos Teruel
 
Minicurso - Técnicas de Teste e Automatização do Teste de Unidade XII SemanaT...
Minicurso - Técnicas de Teste e Automatização do Teste de Unidade XII SemanaT...Minicurso - Técnicas de Teste e Automatização do Teste de Unidade XII SemanaT...
Minicurso - Técnicas de Teste e Automatização do Teste de Unidade XII SemanaT...
Claudinei Brito Junior
 
Testes Automatizados de Software
Testes Automatizados de SoftwareTestes Automatizados de Software
Testes Automatizados de Software
Maurício Aniche
 
Por que automatizar testes de software?
Por que automatizar testes de software?Por que automatizar testes de software?
Por que automatizar testes de software?
Samuel Lourenço
 
Teste Driven Development
Teste Driven DevelopmentTeste Driven Development
Teste Driven Development
Eduardo Carvalho
 
Palestra Testes De Unidade Com JUnit
Palestra Testes De Unidade Com JUnitPalestra Testes De Unidade Com JUnit
Palestra Testes De Unidade Com JUnit
Paulo César M Jeveaux
 
Test-Driven Development (TDD) utilizando o framework xUnit.net
Test-Driven Development (TDD) utilizando o framework xUnit.netTest-Driven Development (TDD) utilizando o framework xUnit.net
Test-Driven Development (TDD) utilizando o framework xUnit.net
Renato Groff
 
Test-Driven Development with PHP
Test-Driven Development with PHPTest-Driven Development with PHP
Test-Driven Development with PHP
Cezar Souza
 
Testes de Sistema
Testes de SistemaTestes de Sistema
Testes de Sistema
Mauricio Volkweis Astiazara
 
Introdução a testes automatizados
Introdução a testes automatizadosIntrodução a testes automatizados
Introdução a testes automatizados
Thiago Ghisi
 
Gof design patterns
Gof design patternsGof design patterns
Gof design patterns
Eduardo Carvalho
 
J unit xp
J unit xpJ unit xp
J unit xp
Emir Calife
 
TDD na Prática
TDD na PráticaTDD na Prática
TDD na Prática
Rafael Fuchs, PMP, MBA
 
TDD com Python (Completo)
TDD com Python (Completo)TDD com Python (Completo)
TDD com Python (Completo)
Osvaldo Santana Neto
 
JUnit Sample
JUnit SampleJUnit Sample

Mais procurados (20)

Apresentacao Testes de Unidade
Apresentacao Testes de UnidadeApresentacao Testes de Unidade
Apresentacao Testes de Unidade
 
Introdução a testes unitários com jUnit
Introdução a testes unitários com jUnitIntrodução a testes unitários com jUnit
Introdução a testes unitários com jUnit
 
Testes de Unidade com JUnit
Testes de Unidade com JUnitTestes de Unidade com JUnit
Testes de Unidade com JUnit
 
Java 12
Java 12Java 12
Java 12
 
Testes Unitários/Integrados
Testes Unitários/IntegradosTestes Unitários/Integrados
Testes Unitários/Integrados
 
Qualidade no desenvolvimento de Software com TDD e PHPUnit
Qualidade no desenvolvimento de Software com TDD e PHPUnitQualidade no desenvolvimento de Software com TDD e PHPUnit
Qualidade no desenvolvimento de Software com TDD e PHPUnit
 
Minicurso - Técnicas de Teste e Automatização do Teste de Unidade XII SemanaT...
Minicurso - Técnicas de Teste e Automatização do Teste de Unidade XII SemanaT...Minicurso - Técnicas de Teste e Automatização do Teste de Unidade XII SemanaT...
Minicurso - Técnicas de Teste e Automatização do Teste de Unidade XII SemanaT...
 
Testes Automatizados de Software
Testes Automatizados de SoftwareTestes Automatizados de Software
Testes Automatizados de Software
 
Por que automatizar testes de software?
Por que automatizar testes de software?Por que automatizar testes de software?
Por que automatizar testes de software?
 
Teste Driven Development
Teste Driven DevelopmentTeste Driven Development
Teste Driven Development
 
Palestra Testes De Unidade Com JUnit
Palestra Testes De Unidade Com JUnitPalestra Testes De Unidade Com JUnit
Palestra Testes De Unidade Com JUnit
 
Test-Driven Development (TDD) utilizando o framework xUnit.net
Test-Driven Development (TDD) utilizando o framework xUnit.netTest-Driven Development (TDD) utilizando o framework xUnit.net
Test-Driven Development (TDD) utilizando o framework xUnit.net
 
Test-Driven Development with PHP
Test-Driven Development with PHPTest-Driven Development with PHP
Test-Driven Development with PHP
 
Testes de Sistema
Testes de SistemaTestes de Sistema
Testes de Sistema
 
Introdução a testes automatizados
Introdução a testes automatizadosIntrodução a testes automatizados
Introdução a testes automatizados
 
Gof design patterns
Gof design patternsGof design patterns
Gof design patterns
 
J unit xp
J unit xpJ unit xp
J unit xp
 
TDD na Prática
TDD na PráticaTDD na Prática
TDD na Prática
 
TDD com Python (Completo)
TDD com Python (Completo)TDD com Python (Completo)
TDD com Python (Completo)
 
JUnit Sample
JUnit SampleJUnit Sample
JUnit Sample
 

Semelhante a Testes de Unidade com Junit

Apresentação testes white box
Apresentação testes white boxApresentação testes white box
Apresentação testes white box
Bárbara Cabral da Conceição, CTFL
 
Testes Funcionais - Unidade IV
Testes Funcionais - Unidade IVTestes Funcionais - Unidade IV
Testes Funcionais - Unidade IV
João Lourenço
 
Introdução a Testes de Software - Unidade I
Introdução a Testes de Software - Unidade IIntrodução a Testes de Software - Unidade I
Introdução a Testes de Software - Unidade I
João Lourenço
 
Teste de Integração - Unidade III
Teste de Integração - Unidade IIITeste de Integração - Unidade III
Teste de Integração - Unidade III
João Lourenço
 
Testes unitários x unit
Testes unitários   x unitTestes unitários   x unit
Testes unitários x unit
Lucas Marques
 
Desenvolvimento Guiado por Testes
Desenvolvimento Guiado por TestesDesenvolvimento Guiado por Testes
Desenvolvimento Guiado por Testes
elliando dias
 
TDD com Python
TDD com PythonTDD com Python
TDD com Python
Osvaldo Santana Neto
 
Teste de software
Teste de softwareTeste de software
Teste de software
Rafael Sanches
 
1 2 3 - Testando - Automatizando os testes de software
1 2 3 - Testando - Automatizando os testes de software1 2 3 - Testando - Automatizando os testes de software
1 2 3 - Testando - Automatizando os testes de software
Heider Lopes
 
TDD (Test-Driven Development)
TDD (Test-Driven Development)TDD (Test-Driven Development)
TDD (Test-Driven Development)
Renato Groff
 
Testes O que são e para que servem? - LadyTalks
Testes O que são e para que servem? - LadyTalksTestes O que são e para que servem? - LadyTalks
Testes O que são e para que servem? - LadyTalks
Diana Ungaro Arnos
 
Gerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptxGerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptx
Roberto Nunes
 
Introdução à Engenharia de Testes de Software
Introdução à Engenharia de Testes de SoftwareIntrodução à Engenharia de Testes de Software
Introdução à Engenharia de Testes de Software
Cloves da Rocha
 
O que é Teste de Software?
O que é Teste de Software?O que é Teste de Software?
O que é Teste de Software?
testedesoftwarepe
 
6. apresentacao rp tec com 2018 igor rozani e felipe muniz
6. apresentacao rp tec com 2018 igor rozani e felipe muniz6. apresentacao rp tec com 2018 igor rozani e felipe muniz
6. apresentacao rp tec com 2018 igor rozani e felipe muniz
Matheus de Lara Calache
 
Testes de unidade - RP Tec Com
Testes de unidade - RP Tec ComTestes de unidade - RP Tec Com
Testes de unidade - RP Tec Com
Igor Rozani
 
TDD (Resumo)
TDD (Resumo)TDD (Resumo)
TDD (Resumo)
Denis Ferrari
 
Desenvolvimento Dirigido por Testes
Desenvolvimento Dirigido por TestesDesenvolvimento Dirigido por Testes
Desenvolvimento Dirigido por Testes
Camilo Ribeiro
 
Testes Unitários - 1 Sessão beiraJUG
Testes Unitários - 1 Sessão beiraJUGTestes Unitários - 1 Sessão beiraJUG
Testes Unitários - 1 Sessão beiraJUG
beiraJUG
 
Fundamentos de Teste de Software - Dev in PF. por Aline Zanin
Fundamentos de Teste de Software - Dev in PF. por Aline ZaninFundamentos de Teste de Software - Dev in PF. por Aline Zanin
Fundamentos de Teste de Software - Dev in PF. por Aline Zanin
DevInPF
 

Semelhante a Testes de Unidade com Junit (20)

Apresentação testes white box
Apresentação testes white boxApresentação testes white box
Apresentação testes white box
 
Testes Funcionais - Unidade IV
Testes Funcionais - Unidade IVTestes Funcionais - Unidade IV
Testes Funcionais - Unidade IV
 
Introdução a Testes de Software - Unidade I
Introdução a Testes de Software - Unidade IIntrodução a Testes de Software - Unidade I
Introdução a Testes de Software - Unidade I
 
Teste de Integração - Unidade III
Teste de Integração - Unidade IIITeste de Integração - Unidade III
Teste de Integração - Unidade III
 
Testes unitários x unit
Testes unitários   x unitTestes unitários   x unit
Testes unitários x unit
 
Desenvolvimento Guiado por Testes
Desenvolvimento Guiado por TestesDesenvolvimento Guiado por Testes
Desenvolvimento Guiado por Testes
 
TDD com Python
TDD com PythonTDD com Python
TDD com Python
 
Teste de software
Teste de softwareTeste de software
Teste de software
 
1 2 3 - Testando - Automatizando os testes de software
1 2 3 - Testando - Automatizando os testes de software1 2 3 - Testando - Automatizando os testes de software
1 2 3 - Testando - Automatizando os testes de software
 
TDD (Test-Driven Development)
TDD (Test-Driven Development)TDD (Test-Driven Development)
TDD (Test-Driven Development)
 
Testes O que são e para que servem? - LadyTalks
Testes O que são e para que servem? - LadyTalksTestes O que são e para que servem? - LadyTalks
Testes O que são e para que servem? - LadyTalks
 
Gerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptxGerenciamento da Qualidade de Software 4.pptx
Gerenciamento da Qualidade de Software 4.pptx
 
Introdução à Engenharia de Testes de Software
Introdução à Engenharia de Testes de SoftwareIntrodução à Engenharia de Testes de Software
Introdução à Engenharia de Testes de Software
 
O que é Teste de Software?
O que é Teste de Software?O que é Teste de Software?
O que é Teste de Software?
 
6. apresentacao rp tec com 2018 igor rozani e felipe muniz
6. apresentacao rp tec com 2018 igor rozani e felipe muniz6. apresentacao rp tec com 2018 igor rozani e felipe muniz
6. apresentacao rp tec com 2018 igor rozani e felipe muniz
 
Testes de unidade - RP Tec Com
Testes de unidade - RP Tec ComTestes de unidade - RP Tec Com
Testes de unidade - RP Tec Com
 
TDD (Resumo)
TDD (Resumo)TDD (Resumo)
TDD (Resumo)
 
Desenvolvimento Dirigido por Testes
Desenvolvimento Dirigido por TestesDesenvolvimento Dirigido por Testes
Desenvolvimento Dirigido por Testes
 
Testes Unitários - 1 Sessão beiraJUG
Testes Unitários - 1 Sessão beiraJUGTestes Unitários - 1 Sessão beiraJUG
Testes Unitários - 1 Sessão beiraJUG
 
Fundamentos de Teste de Software - Dev in PF. por Aline Zanin
Fundamentos de Teste de Software - Dev in PF. por Aline ZaninFundamentos de Teste de Software - Dev in PF. por Aline Zanin
Fundamentos de Teste de Software - Dev in PF. por Aline Zanin
 

Mais de cejug

PUG 2009
PUG 2009PUG 2009
PUG 2009
cejug
 
Pug2009 documento final
Pug2009 documento finalPug2009 documento final
Pug2009 documento final
cejug
 
Conhecendo os Padrões De Projetos
Conhecendo os Padrões De ProjetosConhecendo os Padrões De Projetos
Conhecendo os Padrões De Projetos
cejug
 
Anatomia do JSF – JavaServer Faces
Anatomia do JSF – JavaServer FacesAnatomia do JSF – JavaServer Faces
Anatomia do JSF – JavaServer Faces
cejug
 
Apresentando o CEJUG
Apresentando o CEJUGApresentando o CEJUG
Apresentando o CEJUG
cejug
 
A Iniciativa JEDI, O ensino de Java livre e gratuito
A Iniciativa JEDI, O ensino de Java livre e gratuitoA Iniciativa JEDI, O ensino de Java livre e gratuito
A Iniciativa JEDI, O ensino de Java livre e gratuito
cejug
 
Implementando MVC com AJAX
Implementando MVC com AJAXImplementando MVC com AJAX
Implementando MVC com AJAX
cejug
 

Mais de cejug (7)

PUG 2009
PUG 2009PUG 2009
PUG 2009
 
Pug2009 documento final
Pug2009 documento finalPug2009 documento final
Pug2009 documento final
 
Conhecendo os Padrões De Projetos
Conhecendo os Padrões De ProjetosConhecendo os Padrões De Projetos
Conhecendo os Padrões De Projetos
 
Anatomia do JSF – JavaServer Faces
Anatomia do JSF – JavaServer FacesAnatomia do JSF – JavaServer Faces
Anatomia do JSF – JavaServer Faces
 
Apresentando o CEJUG
Apresentando o CEJUGApresentando o CEJUG
Apresentando o CEJUG
 
A Iniciativa JEDI, O ensino de Java livre e gratuito
A Iniciativa JEDI, O ensino de Java livre e gratuitoA Iniciativa JEDI, O ensino de Java livre e gratuito
A Iniciativa JEDI, O ensino de Java livre e gratuito
 
Implementando MVC com AJAX
Implementando MVC com AJAXImplementando MVC com AJAX
Implementando MVC com AJAX
 

Testes de Unidade com Junit

  • 2. Palestra Café com Tapioca: Testes de Unidade com Junit Instrutor: Fabrício Lemos 15/12/2007
  • 3. Agenda ● Conceito de Testes de Unidade ● Junit ● EasyMock ● DbUnit ● Desenvolvimento Guiado por Testes - TDD
  • 4. Testes de Software ● É um tópico importante e vital no desenvolvimento de software ● Todo mundo sabe que testes precisam ser feitos ● Existe uma quantidade enorme de aspectos que precisam ser testados em um sistema
  • 5. Testes de Software ● O sistema deve passar por diversos tipos de teste antes de entrar em produção – Unidade – Integração – Funcional – Stress e performance – Aceitação
  • 6. Testes de Software ● É praticamente impossível evitar que erros sejam inseridos no código – Atividade complexa – Manipula uma grande quantidade de elementos abstratos – Inclusões de novas funcionalidades podem influenciar nas já existentes – Muitas vezes é difícil ter certeza que o código está totalmente correto até que ele seja executado – Geralmente os desenvolvedores do projeto possuem diferentes níveis de habilidades
  • 7. Testes de Software ● Mesmo tendo reconhecida importância no desenvolvimento de software, os teste costumam ser vistos como uma atividade chata e repetitiva – Só costumam receber atenção quando os problemas começam a ser tornar comuns ● Geralmente só são iniciados quando o produto está todo “pronto”
  • 8. Testes de Software ● Muitos projetos assumem que o código desenvolvido está livre de erros e postergam os testes para as fases finais do desenvolvimento – Preferem remediar do que prevenir – “Está tudo pronto, só falta testar”
  • 9. Testando o Código da Aplicação ● Como ter certeza de que o código escrito faz o que deveria fazer e não contém erros? ● Abordagens comumente usadas – Escreve-se um método main que chama o método escrito e verifica-se o retorno – Espera-se que a funcionalidade esteja pronta e realiza- se um teste funcional manual ● Os testes são feitos de maneira pontual – Não é possível a realização de testes de regressão
  • 10. Testando o Código da Aplicação ● Testes não são automatizados – Não é possível utiliza-los na integração contínua ● Não são gerados relatórios sobre a execução dos testes ● Testes não são executados de maneira isolada – Maior dificuldade em encontrar a fonte de um erro ● Não há disciplina para a realização dos testes
  • 11. Testes de Unidade ● Examinam o comportamento de uma “unidade de trabalho” distinta – Em java, geralmente representada por um único método ● Unidades de trabalho são testadas de maneira isolada ● Possuem natureza diferente dos testes de integração e de aceitação – examinam como vários componentes interagem
  • 12. Objetivos ● Verificar se um pedaço de código faz o que o desenvolvedor acha que ele faz ● Verificar se um pedaço de código SEMPRE faz o que o desenvolvedor acha que ele faz ● Identificar bugs prematuramente ● Permitir que novas funcionalidades sejam adicionadas sem comprometer as já existentes ● Diminuir o impacto das refatorações de código
  • 13. Vantagens dos Testes de Unidade ● Permite uma grande cobertura dos testes ● Pode facilmente simular condições de erro ● Melhora o trabalho em equipe ● Permite ao desenvolvedor entregar código de qualidade (testado) sem esperar que outras partes estejam prontas ● Dá-lhe a confiança que seu código funciona ● “Alguém” assistindo a alteração/inclusão de novas funcionalidades
  • 14. Vantagens ● Diminui o tempo gasto com depuração de código ● Quando há algum erro, te diz o método que falhou e o motivo da falha ● Melhora a implementação ● Testes de unidade são os primeiros “clientes” do código ● Serve como uma documentação do código ● Aprendizagem por exemplos
  • 15. Vantagens ● São facilmente incorporados na Integração Contínua ● Relatórios sobre a corretude do código e a cobertura dos testes são gerados de maneira automática
  • 16. Junit ● Framework de teste criado por Erich Gamma e Kent Beck ● Possui uma api bastante fácil e simples ● Rapidamente se tornou o framework padrão para testes em Java ● Possui suporte para diversas ferramentas: Eclipse, Maven, Ant, etc....
  • 17. Junit ● Foram desenvolvidas diversas extensões para facilitar os testes de partes específicas de um projeto – EasyMock – DbUnit – StrutsTestCase – Cactus – Shale Test Framework – etc...
  • 18. Escrevendo os Testes public class Calculadora { public int somar(int op1, int op2) { return op1 + op2; } }
  • 19. Escrevendo os Testes import static org.junit.Assert.*; import org.junit.Test; public class TestCalculadora { @Test public void testSomar() { Calculadora calc = new Calculadora(); int resultado = calc.somar(2, 3); assertEquals(5, resultado); } }
  • 21. Se o método passar no teste...
  • 22. Se o método não passar no teste...
  • 23. Outros Asserts void assertEquals(Object expected, Object actual) void assertTrue(boolean condition) void assertFalse(boolean condition) void fail() void assertArrayEquals(Object[] expecteds, Object[] actuals) void assertNull(Object object) void assertNotNull(Object object) void assertEquals(String message, Object expected, Object actual)
  • 24. Boas Práticas ● Cada classe do sistema deve ter sua própria classe testadora ● Cada método do sistema deve ter seu próprio método testador ● O nome das classes testadoras devem seguir o padrão TestNomeClasseTestada – Não prejudica o code completion – Classes reconhecidas automaticamente pelo Maven
  • 25. Boas Práticas ● Pacote da classe testadora deve ser o mesmo da classe testada – Permite o teste de métodos protected ● Classes testadoras devem ser armazenadas em pastas separadas – Facilita o empacotamento da aplicação – src/test/java ● Padrão do Maven
  • 26. Classe Usuario public class Usuario { private String nome; private Integer idade; //get e set... }
  • 27. Validação de um Usuário public boolean validarUsuario(Usuario usr) { if (usr.getIdade() > 0 && usr.getNome().length() > 2) { return true; } return false; }
  • 28. Testando a Validação @Test public void testValidarUsuario() { Usuario usuario = new Usuario(); usuario.setIdade(18); usuario.setNome("Cejug"); boolean resultado = new UsuarioManager().validarUsuario(usuario); assertTrue(resultado); }
  • 29. Testando a Validação @Test public void testValidarInvalido() { Usuario usuario = new Usuario(); usuario.setIdade(18); usuario.setNome(""); boolean resultado = new UsuarioManager().validarUsuario(usuario); assertFalse(resultado); }
  • 30. Isolando os Métodos Testados ● A maioria dos métodos de um sistema possui dependências externas à classe ● Umas das principais características dos testes de unidade é o isolamento das unidades testadas – Permite facilmente identificar o local do erro ● Diminui o tempo de debug – As dependências não precisam estar prontas para que o método seja testado ● Para isolar os métodos testados, as dependências devem ser substituídas por dependências “falsas”
  • 31. Método com Dependência public void inserirUsuario(Usuario usuario) { usuario.setDataCadastro(new Date()); if(validarUsuario(usuario)){ usuarioDAO.inserirUsuario(usuario); } else { throw new IllegalArgumentException(); } }
  • 32. Objetos Mock ● Na realização dos testes (em tempo de execução), as dependências são substituídas por objetos Mock – Injeção de dependência ● Simulam as dependências dos métodos testados ● São objetos “vazios” – Não contém nenhuma lógica ● Podem ser feitos pelo próprio desenvolvedor ou a partir de alguma biblioteca
  • 33. EasyMock ● Biblioteca para geração dinâmica de Mocks ● Gera objetos mock que implementam qualquer interface da aplicação – Possui uma extensão para geração de mocks para classes
  • 34. EasyMock ● Permite verificar se o método testado colaborou corretamente com a dependência – Permite a configuração dos objetos mock ● Quais os argumentos que o mock deve receber do método testado ● Qual deve ser o retorno do método chamado ● Se a chamada deve lançar alguma exceção ● Facilidade para simular condições de erro
  • 35. Utilizando Mocks 1.Criar o mock da interface a ser simulada 2.Configurar o comportamento do mock 3.Fazer com que a unidade testada utilize o objeto mock ao invés da dependência original 1.Injetar o Mock 4.Chamar a unidade a ser testada 5.Verificar o valor retornado 6.Verificar se a unidade testada colaborou corretamente com o mock
  • 36. Utilizando Mocks // 1. criando o mock UsuarioDAO mock = EasyMock.createMock(UsuarioDAO.class);
  • 37. Utilizando Mocks // 2. configurando o comportamento do // mock Usuario usuario = new Usuario(); usuario.setIdade(25); usuario.setNome("Café com Tapioca"); mock.inserirUsuario(usuario); EasyMock.replay(mock);
  • 38. Utilizando Mocks // 3. Injetando o Mock UsuarioManager manager = new UsuarioManager(); manager.setUsuarioDAO(mock); // 4. chamando o método a ser // testado manager.inserirUsuario(usuario);
  • 39. Utilizando Mocks // 5. Verificando o comportamento do // método assertNotNull(usuario.getDataCadastro()); // 6. Verificando se o método // usuarioDao.inserir() foi chamado com o // usuário passado EasyMock.verify(mock);
  • 40. Mocks – Boas Práticas ● Sempre utilize injeção de dependências em suas classes ● Acesse as dependências através de suas Interfaces e não através da implementação ● Tenha bem definido qual o comportamento de seus métodos nas interações com as dependências
  • 41. Testando a Camada de Persistência ● Como ter certeza de que seu código de acesso a dados está lendo e escrevendo corretamente na base de dados? ● É necessária uma integração com o banco de dados na realização dos testes – Misto entre teste de unidade e teste de integração ● Quando feita de forma não automática, a verificação depende da inspeção visual do conteúdo da base de dados
  • 42. Testando a Camada de Persistência ● Para automatizar os testes duas condições tem que ser satisfeitas – O conteúdo da base de dados tem ser conhecido no início de cada teste – Deve ser possível verificar o conteúdo da base de dados após cada teste ● Os testes ainda devem ser realizados independentemente – Testar a inserção independentemente da seleção
  • 43. DbUnit ● Extensão do Junit especializada em testes integrados ao banco de dados ● Permite o controle do conteúdo armazenado na base de dados – Exporta dados para a base através de arquivos XML ● Possui métodos de verificação do estado da base de dados – Importa dados da base e compara com arquivos XML
  • 44. Testando com o DbUnit ● O conteúdo da base de dados é configurado através de DataSet no formato XML ● Por default, antes de cada teste a base de dados é esvaziada e re-populada com o conteúdo do DataSet <dataset> <Usuario codigo="-1" nome="josefino" idade="20" /> <Usuario codigo="-2" nome="maria" idade="40" /> <Usuario codigo="-3" nome="jose" idade="40" /> </dataset>
  • 45. Testando com o DbUnit ● Classe de teste deve herdar de DatabaseTestCase ● Implementar os métodos – IDatabaseConnection getConnection() ● Retorna uma conexão com a base de dados – IDataSet getDataSet() ● Retorna o DataSet para o povoamento da base de dados
  • 46. Testando com o DbUnit protected IDatabaseConnection getConnection() throws ClassNotFoundException, SQLException { Class.forName("org.hsqldb.jdbcDriver"); Connection jdbcConnection = DriverManager.getConnection( "jdbc:hsqldb:sample", "sa", ""); return new DatabaseConnection(jdbcConnection); }
  • 47. Testando com o DbUnit protected IDataSet getDataSet() throws DataSetException, IOException { FileInputStream fileIS = new FileInputStream("dataset.xml"); return new FlatXmlDataSet(fileIS); }
  • 48. Testando a Seleção de Usuários public interface UsuarioDAO { List<Usuario> selecionarUsuarios( String nome); }
  • 49. Realizando o Teste ● Montar o(s) parâmetro(s) para a busca ● Criar o retorno esperado de acordo com o DataSet de povoamento da base de dados ● Realizar a busca ● Verificar se o resultado da busca é igual ao resultado esperado
  • 50. @Test public void testSelecionarUsuarios() { String parametroBusca = "jose"; List<Usuario> esperado = new ArrayList<Usuario>(); esperado.add(new Usuario(-3L)); esperado.add(new Usuario(-1L)); List<Usuario> retorno usuarioDAO. selecionarUsuarios(parametroBusca); assertEquals(esperado, retorno); }
  • 51. Desenvolvimento Guiado por Testes (TDD) ● A escrita de testes ajuda na melhoria do design do código ● Ao se perceber os benefícios dos testes, a tendência é escreve-los o quanto antes ● Com o alcance da maturidade, durante a implementação de um método o desenvolvedor já imagina como irá testa-lo
  • 52. TDD ● Quanto mais cedo os testes são implementados, maiores são os benefícios – Evita que bugs se espalhem pela aplicação e os tornam mais fáceis de ser corrigidos ● Os adeptos do TDD levam essa prática ao estremo – Os testes são escritos antes do código a ser testado
  • 53. TDD ● A regra básica do TDD é somente escrever código se existir algum teste falhando – Regra válida para implementação de novas funcionalidades ou para correção de bugs ● Somente o código estritamente necessário para fazer o teste passar deve ser escrito – Refatorações são permitidas
  • 54. Codificando com TDD ● Escreva o teste para a funcionalidade desejada – O teste irá falhar ● Escreva o código necessário e suficiente para o teste passar ● Refatore o código – Elimine possíveis duplicações de código ● Repita os passos quantas vezes necessário ● Entregue o código
  • 55. Vantagens do TDD ● Antes mesmo de começar a implementar o método, o desenvolvedor já tem definido qual será seu comportamento ● O código já nasce sem vícios de design ● Evita que bugs sejam adicionados ao código
  • 56. Vantagens do TDD ● Mantém o desenvolvedor focado no problema a ser resolvido – Código é o mais simples que funciona ● Não procura antecipar mudanças – Manutenção é garantida pela não duplicidade e pela simplicidade do código
  • 57. Duvidas??? ● Contato –fabricio.lemos@gmail.com – discussao@cejug.dev.java.net
  • 58. Referências ● http://www.junit.org/ ● http://www.easymock.org/ ● http://dbunit.sourceforge.net/ ● JUnit in Action – Vincent Massol ● JUnit Recipes: Practical Methods for Programmer Testing – J. B. Rainsberger ● Extreme Programming – Vinicius Manhaes Teles