Você está na página 1de 21

GERÊNCIA E QUALIDADE

DE SOFTWARE

Teste de unidade
Automação de testes
• Deve-se buscar automatizar o máximo possível
• Nem tudo pode ser automatizado
• Processamento paralelo, teste de usabilidade etc.
• Analisar o custo benefício

2
Automação de testes
• Importância de automatizar os testes
• Facilita atividade de testes
• Software é testado frequentemente
• Mais defeitos são encontrados
• Serve como uma especificação do software
• Dá confiança aos programadores
Princípios
• Alguns princípios (MESZAROS, 2007)
• Projete o código para ser testável
• Comunique a intenção do teste
• Não altere o software para permitir os testes
• (Alteração manual que precisa ser corrigida)
• Mantenha os testes independentes
• Isole a unidade sendo testada
• Minimize a sobreposição dos testes
• Mantenha a lógica de teste fora do código de produção
• Verifique uma condição por teste 4
Teste de unidade
• Quando criar o teste de unidade?
• Antes de programar a classe (TDD)
• Depois de programar a classe

• O que testar?
• Teste intramétodos: unidade
• Teste intermétodos: unidade X integração
• Teste intraclasse: unidade X integração
• Teste interclasses: integração 5
Exemplo
public class Calculadora {
private int resultado;
public int somar(int v1, int v2) {
resultado = v1 + v2;
return resultado;
}
public int dividir(int dividendo, int divisor) {
if (divisor == 0)
throw new ArithmeticException("Divisao por zero");
resultado = dividendo / divisor;
return resultado;
}
public int getUltimoResultado() {
return resultado;
}
} 6
Como testar
• Usaremos o framework Junit
• http://junit.org
• É praticamente um padrão para Java
• Existem versões do framework para outras linguagens

• Uso integrado a vários IDEs


• (Usaremos o JUnit 4)

7
Como testar
• Os testes ficarão em uma outra classe
• Calculadora → CalculadoraTeste
• (Sugestão)

• Separe os testes
• Mantenha a mesma estrutura de pacotes da aplicação
• O teste deve ficar no mesmo pacote da classes testada
• Acesso aos métodos friendly
Formato básico
import static org.junit.Assert.*;
import org.junit.Test;
import org.junit.Before; O static é para usar métod
de escopo de classe sem
public class ExemploTest { colocar o nome da classe
@Before
public void inicializa() {
...
}
@Test
public void metodoDeTeste() {
...
}
} 9
Alguns métodos úteis
• assertTrue(boolean condição)
• Verifica se a condição é verdadeira
• assertFalse(boolean condição)
• Verifica se a condição é falsa
• fail()
• Faz o código falhar
• assertEquals(double esperado, double obtido,
double delta)
• Verifica se (obtido - delta ≤ valorEsperado ≤ obtido + delta)
10
public class CalculadoraTest {
Exemplo Calculadora c;
@Before
public void inicializacao() {
c = new Calculadora();
}
@Test
public void somaComValoresPositivos() {
assertTrue(c.somar(1, 1) == 2);
}
@Test
public void somaComValoresNegativos() {
assertTrue(c.somar(-1, -1) == -2);
}
}
Dependências
• O que fazer com as dependências?
• Princípio: isole a parte a ser testada do resto do sistem

• Exemplo: calculadora com memória


Memoria
CalculadoraComMemoria m: Deque<Integer>
salvar(valor: int)
adicionar(valor: int) 1 getUltimoValor(): int
somar(v: int): int resetar()
estaVazia(): boolean
12
Exemplo
ublic class CalculadoraComMemoria {
private Memoria m = new Memoria();

public void adicionar(int valor) {


m.salvar(valor);
}

public int somar(int v) {


if (m.estaVazia()) throw new RuntimeException("Memoria vazia")
int resultado = m.getUltimoValor() + v;
m.salvar(resultado);
return resultado;
}
Exemplo
ublic class CalculadoraComMemoria {
private Memoria m;

public CalculadoraComMemoria(Memoria m) {
this.m = m;
}

public void adicionar(int valor) {


m.salvar(valor);
}
..
Dependência

• Uma solução simples: Stub


Exemplo
ublic class CalculadoraComMemoriaTest {
@Test
public void somaComValoresPositivos() {
CalculadoraComMemoria c =
new CalculadoraComMemoria(new MemoriaParaTeste());
c.adicionar(1);
assertTrue(c.somar(1) == 2);
}
Stub
class MemoriaParaTeste extends Memoria {
public void salvar(int valor) {
}
public int getUltimoValor() {
return 1;
}
public void resetar() {
}
public boolean estaVazia() {
return false;
}
}
Problemas
• Não garantem que os métodos sejam chamados
do jeito certo
• Parâmetros
• Sequência correta
• Não verificam se um método não foi chamado
• É preciso criar uma nova classe para cada teste
• Classes anônimas ajudam, mas não resolvem
• Solução mais elegante: mock
Dicas
• Faça o teste estrutural e funcional
• Coloque valores diretamente na asserção
assertTrue(c.calcular() == x * y + z); X
• Não use valores aleatórios
• Não teste métodos triviais
• ...getters e setters...
Bibliografia

• MESZAROS, G. xUnit Test Patterns:


Refactoring Test Code. Addison Wesley, 2007.

20
GERÊNCIA E QUALIDADE
DE SOFTWARE

Teste de unidade

Você também pode gostar