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…

TriadWorks: Deploy Automatizado

Aprenda como Automatizar seu Deploy em 15min…

Você faz deploy da sua aplicação manualmente? Em produção? Não cara, não faz isso.

Você sabe que esse processo manual cedo ou tarde vai te trazer uma grande dor de cabeça, né? Qualquer tarefa manual, repetitiva e feita por um ser humano tende a não dar certo.

A melhor forma de resolver isso é automatizando: desde build até o processo de deploy. Automatizar o deploy não precisa ser algo difícil nem sofisticado, você consegue resolver isso com 2 passos simples:

  1. liste todos os passos do deploy num arquivo TXT;
  2. transforme essa lista num script executável;

Pronto! A partir de agora você tem um processo de deploy automatizado sem firulas! Não sabe escrever o script? Não te preocupas, eu te ensino como fazer nesse novo post no blog:

[Post] Deploy Automatizado: feito é melhor que perfeito

Deploy deve ser simples e executado com frequência, dessa forma você diminui os riscos a cada nova versão da sua aplicação.

E aí, o que achou? Será que você consegue aplicar o script do post no seu trabalho? Comenta lá, deixa eu saber!

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!