Category: TDD

Semana passada tivemos uma reunião na empresa em que trabalho sobre os procedimentos de controle de qualidade dos softwares que produzimos. Antes de fazer o release de um software é necessário que sejam tomadas algumas precauções básicas para garantir que ele funcione satisfatoriamente em produção e estávamos apresentando para os nossos gerentes e equipe de controle de qualidade da empresa as ferramentas e procedimentos adotados pela nossa equipe para isto.

Das várias medidas que estamos tomando, talvez a principal por ser a base para todas as outras direta ou indiretamente é o “desenvolvimento guiado pelos testes” ou “test driven development” (TDD para os mais íntimos).

No TDD você desenvolve os testes do software antes mesmo de desenvolver o software. A cada peça da aplicação que é construída uma série de testes são escritos ANTES do desenvolvimento para garantir que a aplicação funciona como deveria funcionar.

O conceito de TDD é bem simples de ser aplicado mas para quem não está acostumado com testes unitários e práticas de desenvolvimento ágil pode parecer meio estranho e ser um pouco mais difícil de entender.

Inspirado nesse cenário vou tentar explicar rapidamente como funciona o TDD com um exemplo prático e bem simples. Vou explicar seguindo a linha de raciocínio que normalmente se tem em tempo de programação pois a maneira de pensar no processo de desenvolvimento também faz parte do TDD.

Imagine que você está desenvolvendo um sistema no qual um usuário deve cadastrar seu endereço. O CEP digitado precisa ser validado para que tenha o formato 00000-000 e para isso será necessário desenvolver uma classe que faça a validação dos dados. Vamos definir a interface para esta classe de validação de dados:

public interface ValidadorDeDados {
    boolean isCepValido(String cep);
}

A partir deste ponto já temos o comportamento do nosso validador claramente definido: dada uma String contendo o valor de um CEP ele retornará verdadeiro se o CEP for válido e falso caso contrário. Por exemplo, se o validador receber uma String “teste” ou “” obviamente deverá retornar falso. Por outro lado se ele receber uma String “00000-000” ou “12345-123” deverá retornar verdadeiro.

Então já podemos desenvolver uma classe de teste que faça estas verificações e mais algumas outras pertinentes. Vou utilizar para os testes o framework JUnit que é o framework de testes unitários Java mais popular do mercado.

public class ValidadorDeDadosTest extends TestCase {
    private ValidadorDeDados validador = null; // instância de validador de dados para o teste
 
    public void testIsCepValido() {
        assertFalse("retorno deve ser FALSE", validador.isCepValido(null));
        assertFalse("retorno deve ser FALSE", validador.isCepValido(""));
        assertFalse("retorno deve ser FALSE", validador.isCepValido("iodfjodfd"));
        assertFalse("retorno deve ser FALSE", validador.isCepValido("03490340"));
        assertTrue("retorno deve ser TRUE", validador.isCepValido("20202-020"));
        assertTrue("retorno deve ser TRUE", validador.isCepValido("00000-000"));
        assertTrue("retorno deve ser TRUE", validador.isCepValido("99999-999"));
    }
}

Para quem não conhece o JUnit, o método assertFalse checa se o retorno da execução retornou falso e o método assertTrue checa se o retorno da execução retornou verdadeiro. Em todos os casos que o assertTrue foi utilizado o validador deverá retornar verdadeiro e o oposto deverá acontecer para os assertFalse. Se isto não acontecer, significa que tem alguma coisa errada.

Além disso colocamos uma pequena mensagem explicando o que esperamos que aconteça na execução do método. Isso é util para que outros desenvolvedores da equipe possam entender com facilidade o que você programou e está esperando que aconteça nos seus testes, bem como para deixar as mensagens de erro mais explicativas.

Só para não deixar dúvida nenhuma, vamos ler uma das linhas de teste:

assertFalse("retorno deve ser FALSE", validador.isCepValido(""));

Que é: Ao executar a validação do CEP “”, certifique-se que ele retornará FALSO.

Então vamos executar o teste para ver o que vai acontecer:

Ele falhou com NullPointerException porque não há uma implementação de validador, desenvolvemos somente a interface. No teste unitário o validador está setado como null.

Sendo assim, vamos desenvolver a primeira implementação de validador:

public class ValidadorDeDadosImpl implements ValidadorDeDados {
    public boolean isCepValido(String cep) {
        return false;
    }
}

Além disso é necessário alterar a classe de teste para utilizar esta implementação de validador de dados que desenvolvemos.

public class ValidadorDeDadosTest extends TestCase {
    private ValidadorDeDados validador = new ValidadorDeDadosImpl(); // agora o validador não é mais null
 
    public void testIsCepValido() {
        assertFalse("retorno deve ser FALSE", validador.isCepValido(null));
        assertFalse("retorno deve ser FALSE", validador.isCepValido(""));
        assertFalse("retorno deve ser FALSE", validador.isCepValido("iodfjodfd"));
        assertFalse("retorno deve ser FALSE", validador.isCepValido("03490340"));
        assertTrue("retorno deve ser TRUE", validador.isCepValido("20202-020"));
        assertTrue("retorno deve ser TRUE", validador.isCepValido("00000-000"));
        assertTrue("retorno deve ser TRUE", validador.isCepValido("99999-999"));
    }
}

Agora o teste já está rodando, o resultado foi bem diferente. Antes estava sendo lançada uma exception porque a implementação do validador de dados sequer existia. Agora o que acontece é que temos um problema na implementação do validador e o teste acusou isso:

Veja a implementação do validador de dador e repare que independente da String passada para o método ele retorna falso, ou seja, está errado. Vamos corrigir essa implementação:

public class ValidadorDeDadosImpl implements ValidadorDeDados {
    public boolean isCepValido(String cep) {
        if ((cep == null) || (cep.length() != 9) || cep.charAt(5) != '-') {
                return false;
        }
        return true;
    }
}

E executando novamente os testes podemos verificar que agora todos estão passando:

Desenvolvimento finalizado? Nada disso. Navegando pelo sistema e fazendo outros testes manuais descobrimos que é possível entrar com um CEP com letras tipo ABCDE-FGH. Se analisarmos a implementação do método veremos que isso realmente é possível. Não há nenhuma verificação que impeça isto.

Mas caramba, os testes não passaram? É verdade, os testes ainda estão passando. Acabamos de descobrir um bug.

Quando um bug é descoberto ou é reportado para a equipe de desenvolvimento, a primeira coisa a se fazer é escrever um teste para comprovar a existência do bug. Vamos então complementar a nossa classe de teste:

public class ValidadorDeDadosTest extends TestCase {
    private ValidadorDeDados validador = new ValidadorDeDadosImpl();
 
    public void testIsCepValido() {
        assertFalse("retorno deve ser FALSE", validador.isCepValido(null));
        assertFalse("retorno deve ser FALSE", validador.isCepValido(""));
        assertFalse("retorno deve ser FALSE", validador.isCepValido("iodfjodfd"));
        assertFalse("retorno deve ser FALSE", validador.isCepValido("03490340"));
        assertTrue("retorno deve ser TRUE", validador.isCepValido("20202-020"));
        assertTrue("retorno deve ser TRUE", validador.isCepValido("00000-000"));
        assertTrue("retorno deve ser TRUE", validador.isCepValido("99999-999"));
    }
 
    public void testIsCepValidoComLetras() {
        assertFalse("retorno deve ser FALSE", validador.isCepValido("AAAAA-AAA"));
        assertFalse("retorno deve ser FALSE", validador.isCepValido("A2AA1-333"));
        assertFalse("retorno deve ser FALSE", validador.isCepValido("x2334-567"));
    }
}

Executando os testes novamente vemos que o teste que acabamos de escrever falhou. Ao entrar com este CEP o validador deveria retornar falso pois é um CEP inválido mas ele está retornando verdadeiro. Muito bem, o bug está comprovado:

Repare que somente o teste novo está falhando, os testes antigos estão passando normalmente (em verde).

Com os testes prontos já podemos fazer a correção na implementação:

public class ValidadorDeDadosImpl implements ValidadorDeDados {
    public boolean isCepValido(String cep) {
        if ((cep == null) || (cep.length() != 9) || cep.charAt(5) != '-') {
            return false;
        }
        for (int i = 0; i < cep.length(); i++) {
            if (i != 5) {
                char posicao = cep.charAt(i);
                if (!Character.isDigit(posicao)) {
                    return false;
                }
            }
        }
        return true;
    }
}

E corrigida a implementação, vamos executar os testes novamente para verificar se o bug foi corrigido:

Agora sim tudo funcionando.

Podemos perceber como é fácil implementar funcionalidades e corrigir bugs com TDD. Alguns pontos fortes que merecem destaque:

1) Qualquer tipo de implementação por mais complexa que seja será suportada pelos testes e com isso você programa com mais confiança. Dado um comportamento do método que será definido antes do desenvolvimento você pode executar os testes inúmeras vezes até que eles passem. E quando eles passam você tem certeza absoluta de que o que você fez está efetivamente funcionando.

2) TDD facilita o refactoring: depois de cada reescrita de código ou qualquer tipo de alteração, especialmente em códigos que você não conhece bem porque foram feitos por outros membros da equipe, você pode rodar os testes da aplicação inteira afim de garantir que você não está quebrando nenhuma funcionalidade. Alguns sistemas são tão podres que dependendo do lugar que você mexe quebra tudo. Os testes te ajudam a não fazer isso.

3) Mesmo que seja um pouco mais demorado escrever testes ao desenvolver, com esta prática você praticamente não encontra bugs em produção e quando encontra eles podem ser corrigidos rapidamente e com confiança. Então no final das contas você GANHA tempo. E o melhor de tudo é que você programador não precisa ficar pisando em ovos e sem dormir porque mexeu na aplicação. Algumas aplicações são tão difĩceis de serem alteradas (porque são mal programadas) que você vai para casa e dorme com o celular do lado porque tem certeza que ele vai tocar porque deu pau no sistema!

Então, preserve seus cabelos e sua saúde: programe com qualidade! 😉

Download do código fonte.