Testes de Unidade

Justificativa

• Reduzir defeitos (bugs) apresentados pelo produto
• Cobrir uma gama maior de equipamentos e ambientes operacionais do que aqueles disponíveis na empresa através de testes em clientes
• Assegurar a qualidade final do produto para o cliente, incluindo avaliação de embalagem, manuais, usabilidade, etc.

Estágios de testes

• Testes são feitos em vários estágios
• Fazer testes monolíticos do produto inteiro aumentaria o tempo necessário à depuração total do software
• É melhor (mais rápido) testar partes menores para depois testar a integração dessas partes
• Determinados testes devem ser feitos por pessoas fora da equipe de desenvolvimento no sentido de manter a maior objetividade possível nessas fases de testes e no sentido de envolver também os usuários finais fora da empresa

Automatização de testes

• Os testes devem ser automatizados
  • Pelo menos nas fases em que isso é possível
• Scripts de testes desenvolvidos ao longo do tempo aumentam o patrimônio da empresa e garantirão uma qualidade cada vez maior

Tipos de testes

• Testes de unidade
  • Para testar classes individuais
  • Feito pelo próprio programador da classe
  • Testa toda a interface da classe
• Testes funcionais
  • Para testar os Use Cases
  • Feito pelo time de desenvolvimento
• Testes de sistema
  • Uso de Total System Environment
    • Incluindo outros produtos de software, todas as plataformas, todas as configurações, etc.
  • Feito por uma equipe independente de testes
• Testes de regressão
  • Antes de por o sistema na rua, mesmo que tenha havido apenas uma recompilação
  • Normalmente um subconjunto dos testes de sistema
• Teste alfa
  • Teste de produto (com embalagem manual, etc.) num "cliente" dentro da empresa
• Teste beta
  • Como teste alfa mas incluindo clientes fora da empresa

Testes de Unidade

• Necessidade de automação
  • Clica um botão a qualquer momento para testar tudo!
  • Pelo menos um teste por dia (frequentemente vários testes por hora)
• Uso de um framework de testes
• Desenvolvimento e testes em paralelo
• Absolutamente necessário ter testes de unidade, principalmente se fizer refactoring de código
• Testar as classes da menos acoplada para a mais acoplada
  • Na realidade, segue a ordem de desenvolvimento
  • Desenvolvimento e testes de unidade feitos em paralelo!
• Exemplo com o framework JUnit (teste da classe Venda)
  • Neste pacote, leia o artigo "Test Infected: Programmers Love Writing Tests"
  • Escrito por Beck (CRC, Extreme Programming) e Gamma (GoF)
  • Todos os testes estão aqui para o código do capítulo anterior

package tpdv;

import junit.framework.*;
import tpdv.*;

/**
 * Testes da classe Venda.
 *
 */
public class TestaVenda extends TestCase {
    protected IVenda venda1;
    protected IEspecProduto ep1;
    protected IEspecProduto ep2;
    protected IEspecProduto ep3;

    public TestaVenda(String name) {
        super(name);
    }
    public static void main(String[] args) {
        junit.textui.TestRunner.run(suite());
    }
    protected void setUp() {
        venda1 = new Venda();
        ep1 = new EspecificacaoDeProduto(100, 1.99, "prod1");
        ep2 = new EspecificacaoDeProduto(200, 2.99, "prod2");
        ep3 = new EspecificacaoDeProduto(300, 3.99, "prod3");
    }
    public static Test suite() {
        return new TestSuite(TestaVenda.class);
    }
    public void testConstrutor() {
        assert("1", !venda1.equals(null));
        assertEquals("2", 0.0, venda1.total(), 0.0);
        assert("3", !venda1.isTerminada());
    }
    public void testManipulacao() {
        venda1.criaLinhaDetalhe(ep1, 1);
        assertEquals("1", 1.99, venda1.total(), 0.001);
        venda1.criaLinhaDetalhe(ep2, 2);
        assertEquals("2", 1.99+(2*2.99), venda1.total(), 0.001);
        venda1.criaLinhaDetalhe(ep3, 2);
        assertEquals("3", 1.99+(2*2.99)+(2*3.99), venda1.total(), 0.001);
        try {
            venda1.façaPagamento((float)5.0);
            fail("facaPagamento(5.0) deveria gerar exception");
        } catch(PagamentoInsuficienteException e) {
        }
        try {
            venda1.façaPagamento((float)20.0);
        } catch(PagamentoInsuficienteException e) {
          fail("facaPagamento(20.0) nao deveria gerar exception");
        }
        assertEquals("4", 20-1.99-(2*2.99)-(2*3.99), venda1.getTroco(), 0.001);
        assert("3", !venda1.isTerminada());
        venda1.terminou();
        assert("3", venda1.isTerminada());
    }
}

Algumas palavras de Beck e Gamma

• Sometimes you just won't feel like writing tests, especially at first. Don't. However, pay attention to how much more trouble you get into, how much more time you spend debugging, and how much more stress you feel when you don't have tests. We have been amazed at how much more fun programming is and how much more aggressive we are willing to be and how much less stress we feel when we are supported by tests. The difference is dramatic enough to keep us writing tests even when we don't feel like it.

impl-3 programa anterior próxima