junit-exceptions

Como você testa os fluxos alternativos do seu código?

Deixa eu te perguntar: quantos cenários de testes você enxerga no código abaixo:

/**
 * Registrar novo lance no leilão
 */
public void darLance(Lance lance) {
    
    if (lance.getValor() <= 0)
        throw new RuntimeException("Lance com valor negativo");
    
    this.lances.add(lance);
}

E aí, quantos? 1, 2 ou 3 casos de teste? Não é tão simples assim não, é mesmo?

Um especialista de Q&A responderia facilmente, afinal ele estudou muito para isso! Mas nós desenvolvedores temos maior dificuldade, precisamos de experiência para identificar cenários em código e muitas vezes até ferramentas de cobertura de código:

analisando-cobertura-de-codigo-eclemma_large

Não identificar fluxos de negócio em um trecho de código pode trazer diversos bugs para o sistema. Não é por acaso, como testar algo que não conseguimos enxergar?

Não dá né…

Um boa maneira de melhorar sua percepção é escrevendo testes automatizados. Escrever testes aumenta nossa percepção a um nível surpreendente. 

Para te ajudar a entender toda a problemática, acabamos de blogar sobre o assunto e porque você deveria se preocupar com os fluxos alternativos do seu código:

[Post] jUnit: testando fluxos de exceção e erro

Cobrir fluxos alternativos e excepcionais com testes é muito barato se comparado a testes manuais. Você nem vai precisar levantar seu Tomcat outra vez…

PS: e aí, quantos cenários você encontrou? Comenta aí embaixo, vamos bater uma bola…

jUnit: testando classe que mexem com arquivos

Testando classes que lidam com arquivos com jUnit Rules e TemporaryFolder

É quase que mandatório todo projeto Java ter uma classe FileUtils da vida para manipular arquivos… É ou não é?

public class FileUtils {

    /**
     * Lista todos os arquivos de um diretorio
     */
    public static List<File> lista(File diretorio) {
        File[] arquivos = diretorio.listFiles();
        return Arrays.asList(arquivos);
    }

    public static void deleta(File arquivo) { ... }

    public static void copia(File origem, File destino) { ... }

    public static void escreve(File arquivo, String conteudo) { ... }

    // outros métodos
}

Mas infelizmente ela não é levada tão a sério assim! No geral ela é testada manualmente“por tabela” quando testamos outra funcionalidade do sistema.

@Repository
public UsuarioDao {
    
    @Transactional
    public void deleta(Usuario usuario) {
        this.entityManager.remove(usuario);
        FileUtils.deleta(usuario.getFoto()); // deleta foto do disco
    }
}

Essa prática leva a problemas que você já deve conhecer bem, como brechas para bugs! O que fazer então? Simples, cubra a classe com testes automatizados!

Por azar nosso testar uma classe que acessa disco não é tão simples quanto um teste de unidade qualquer, por esse motivo existe alguns detalhes que você precisa saber antes de programar a 1a linha de teste (isso é muito importante!). Para entender estes detalhes, leia o novo post no blog daTriadWorks:

[Blog] Testes de Integração na prática: testando classes que manipulam arquivos com jUnit

De quebra você ainda conhece uma feature do jUnit que facilita em N vezes a escrita dos seus testes e principalmente a vida da equipe:

public class FileUtilsTest {

    @Rule
    public TemporaryFolder temp = new TemporaryFolder();

}

E aí, o que achou da dica? Aproveita e compartilha esse post com seus amigos e sua equipe – dá para tirar boas discussões daí!

Nunca mais repita “na minha máquina funciona”. TDD, Testes e Build Automatizado

Eu não sei você, mas eu repeti inúmeras vezes a frase “na minha máquina funciona” no inicio da minha carreira como desenvolvedor…

Mas quem nunca, né? rs

Desenvolver software não é uma tarefa simples, lidamos com pressão, cobranças e prazos apertados a todo instante, seja do gerente, cliente ou equipe. Você me entende! E ainda temos que garantir que aquele IFzinho que colocamos na última correção de bug funcione:

public void sacar(Conta conta, double valor) {
    if (!conta.temSaldoPara(valor)) { // esqueci dessa regra :-X
        throw new SaldoInsuficienteException();
    }
    // restante do codigo: efetua o saque
}

Mas como garantir essa nova lógica de negócio? Temos que testar! Mas como? Talvez você faça assim:

  1. alterando o saldo no banco;
  2. levantando o Tomcat;
  3. abrindo o Chrome;
  4. fazendo login na aplicação;
  5. preenchendo e submetendo formulários;
  6. verificando se houve o erro na tela;

Tudo isso é enfadonho e pior, é TESTE MANUAL. Um hora você vai esquecer ou errar algum passo e aí já viu né…

Fazer testes manuais NÃO É SUSTENTÁVEL: é CARO e LENTO. Nem todas as empresas podem arcar com isso. Por isso é recomendado escrever TESTES AUTOMATIZADOS. Por exemplo, com Java teríamos algo como:

@Test(expected=SaldoInsuficienteException.class)
public void deveNaoPermitirSacarQuandoEstiverNaLiseira() {

    Conta conta = new Conta("Rafael", 24.99); // titular e saldo atual
    double valorASacar = 90.0; // pra curtir uma Orbita na quinta <3

    CaixaEletronico caixa = new CaixaEletronico();
    caixa.sacar(conta, valorASacar); 
}

Com esse simples teste de unidade garantimos que se não houver saldo na conta a exceção SaldoInsuficienteException é lançada. Se nossa lógica mudar futuramente e esse teste quebrar saberemos que alguém fez caca no código! GENIAL, não?!

A verdade é que TODO desenvolvedor DEVERIA escrever testes. Ele deve garantir minimamente a qualidade do código que ele escreve. Concorda comigo?

Para entender do que estou falando, recomendo a leitura desse novo post no blog. Nele discutimos várias práticas para garantir a qualidade do seu código:

>> Na minha máquina funciona, e na sua? Testes, TDD e build automatizado

O que discuto no post é somente a pontinha do iceberg do que estamos preparando para nosso novo curso de testes com Java. Testes, TDD e práticas de refatoração é obrigatório para qualquer profissional que busca qualidade no software que entrega!

E aí, o que achou do post? Deixa teu comentário lá! Eu leio e respondo todos os comentários!