Introdu��o ao desenvolvimento guiado por teste (TDD) com JUnit

Afinal o que � TDD? TDD � a abreviaç�o de Test Driven Development ou, em traduç�o livre, Desenvolvimento Guiado por Teste. Este artigo apresenta uma introduç�o ao TDD e ao framework JUnit.

Introduç�o ao TDD

A ideia por traz do desenvolvimento guiado por teste � que primeiro devemos escrever os testes para posteriormente escrever o c�digo. Segundo Freeman, Steve; Pryce, Nat(2012) �... Voc� n�o tem nada a perder, a n�o ser seus bugs�. Ainda segundo a Wikip�dia, �Desenvolvimento dirigido por testes � uma t�cnica de desenvolvimento de software que baseia em um ciclo curto de repetiç�es: primeiramente o desenvolvedor escreve um caso de teste automatizado que define uma melhoria desejada ou uma nova funcionalidade. Ent�o, � produzido c�digo que possa ser validado pelo teste para posteriormente o c�digo ser refatorado para um c�digo sob padr�es aceit�veis�. O TDD � parte do processo de desenvolvimento �gil, utilizado em metodologias como o XP (Programaç�o Extrema) e sendo uma das t�cnicas que auxiliam na melhoria de qualidade do processo de desenvolvimento. O TDD ou desenvolvimento guiado por teste torna mais eficiente o processo. A imagem a seguir ilustra os passos do desenvolvimento utilizando TDD:

Figura 1: Passos do TDD

O desenvolvimento guiado por teste d� uma vis�o mais ampla do que deve ser feito ao desenvolvedor, pois antes de criar a funcionalidade, deve-se criar um teste da funcionalidade. Os passos apresentados na figura acima indicam que primeiro � necess�rio criar o teste, este teste � chamado de teste falho, pois a funcionalidade ainda n�o existe, desta forma, o teste deve retornar um erro. Posteriormente ser� desenvolvido o c�digo para fazer com que o teste seja bem sucedido, j� que o desenvolvedor sabe quais funcionalidades deve implementar, fica mais pr�tico o seu desenvolvimento. Por �ltimo refatore, ou seja, melhore a codificaç�o.

O Desenvolvimento guiado por teste � um conjunto de t�cnicas que culminam em um teste de ponta a ponta. Neste artigo, vamos apenas tratar do teste unit�rio, que � um dos procedimentos para o TDD, mas deve-se pensar no conjunto, ou seja, o teste de integraç�o e o teste de aceitaç�o.

Teste unit�rio

O Teste Unit�rio valida apenas um pedaço do sistema, ou seja, uma unidade, sendo utilizado para testar as funcionalidades, exibindo informaç�es sobre seu funcionamento. Para nosso exemplo pr�tico de codificaç�o, vamos utilizar o JUnit como framework de teste unit�rio Java, o conceito aqui utilizado pode ser aplicado ao NUnit, PHPUnit, entre outros.

O JUnit � um framework de teste que utiliza anotaç�es para a identificaç�o de m�todos de ensaio. Lembrando que os testes s�o unit�rios, n�o devendo depender de outros testes para o seu funcionamento. Al�m de utilizar anotaç�es, o framework disponibiliza m�todos de asserç�es, que s�o utilizados para validar informaç�es. Com base nas asserç�es teremos o resultado de nosso teste como falho ou OK.

Nos exemplos utilizaremos o NetBeans que, ao ser instalado, j� possui o JUnit integrado. O Eclipse tamb�m o tem integrado, mas � poss�vel fazer o download caso queira fazer o processo manual.

Para nosso exemplo, ser� criado um novo projeto denominado "Calculo", este projeto ser� utilizado para criar nosso teste e posteriormente nosso c�digo de aceitaç�o para o teste.

Ao criar o projeto, a seguinte estrutura foi montada:

Figura 2: Estrutura do projeto

Primeiramente � necess�rio entender o que vamos testar, visto que criaremos um teste para algo que ainda n�o existe. Neste caso, o cen�rio � o seguinte:

Temos de desenvolver uma classe como soluç�o a um problema de c�lculo simples, devem ser implementados m�todos para soma, subtraç�o, multiplicaç�o e divis�o. Nesse nosso exemplo, queremos apenas fazer o c�lculo de dois n�meros e obter o resultado.

Agora que j� sabemos o que vamos desenvolver, ent�o vamos criar o nosso primeiro teste unit�rio.

Figura 3: Adicionando novo teste

Ser� aberta uma nova janela, conforme a figura a seguir:

Figura 4: Propriedades iniciais do novo teste

O campo "nome da classe" � o nome da classe de teste, vamos dar o nome de "TestCalculo", para sabermos que � um pacote de teste e deve testar a classe Calculo.

Em "c�digo gerado" est�o marcadas as opç�es de inicializador de testes, finalizador etc. Para este exemplo, podemos desmarcar estes itens.

No pr�ximo passo ser� perguntada a vers�o do JUnit a ser utilizada, selecione JUnit 4.X.

Figura 5: Vers�o do JUnit

Crie um Teste JUnit e insira o seguinte c�digo:

import org.junit.Test;
import static org.junit.Assert.*;

/**
 *
 * @author Fabio Gomes Rocha
 */
public class TestCalculo {
    
    public TestCalculo() {
   
    }
    @Test
/**
 *
 * @Description Testa o m�todo soma
 */
    
public void testSoma(){
         System.out.println("Soma");
        int a = 10;
        int b = 20;
        int expResult = 30;
        int result = Calculo.Soma(a, b);
        assertEquals(expResult, result);
    }
    @Test
/**
 *
 * @Description Testa o m�todo subtraç�o
 */

       public void testSubtracao(){
         System.out.println("Subtraç�o");
        int a = 20;
        int b = 10;
        int expResult = 10;
        int result = Calculo.Subtracao(a, b);
        assertEquals(expResult, result);
    }
    @Test
/**
 *
 * @Description Testa o m�todo multiplicaç�o
 */

    public void testMultiplicacao(){
         System.out.println("Multiplicaç�o");
        int a = 5;
        int b = 10;
        int expResult = 50;
        int result = Calculo.Multiplicacao(a, b);
        assertEquals(expResult, result);
    }
    @Test
/**
 *
 * @Description Testa o m�todo divis�o
 */

    public void testDivisao(){
         System.out.println("Divis�o");
        float a = 20;
        float b = 10;
        float expResult = 2;
        float result = Calculo.Divisao(a, b);
        assertEquals(expResult, result,0);
    }
}

Listagem 1. Teste unit�rio para a classe Calculo

Com o teste pronto, antes de entendermos o que est� acontecendo, vamos execut�-lo (Shift + F6). Ap�s a execuç�o, o sistema deve retornar que falhou, neste caso, como temos quatro testes, al�m de falha em 100%, � apresentada a causa do erro. Nesse caso o erro foi ocasionado por falta de implementaç�o da classe Calculo. Um outro ponto importante � que o teste apresenta o tempo que levou para a realizaç�o do teste (1,309 segundos) sendo poss�vel analisar sob este ponto para refatorar o teste e a unidade.

Figura 6: Erros no primeiro teste

Agora que o teste foi falho, vamos entender a codificaç�o do teste de unidade que desenvolvemos.

import org.junit.Test;
import static org.junit.Assert.*;

Est�o importando as classes necess�rias para a realizaç�o dos testes e asserç�es.

Posteriormente, � criado um teste para cada funcionalidade desejada, tomando cuidado com os tipos de retorno a serem testados.

@Teste: Esta anotaç�o indica que o c�digo a seguir � um teste.

public void testSoma(){: M�todo criado para teste, foi dado o nome test (indicando que � um teste) e Soma (indicando qual o m�todo est� sendo testado)

System.out.println("Soma"): Aqui exibe o que est� sendo testado, � apenas uma sa�da comum.

A seguir alguns atributos que ser�o utilizados como par�metro para testar nosso objeto calculo

int a = 10;
int b = 20;
int expResult = 30;

int result = Calculo.Soma(a, b): Agora � feito uma chamada ao m�todo soma do objeto calculo, passando como par�metro as vari�veis a e b. Como � uma soma e demos o valor de a como 10 e b como 20, somando ter�amos 30.

assertEquals(expResult, result): O assertEquals compara duas vari�veis, neste caso o expResult(Resultado esperado) com a vari�vel result que traz o resultado obtido pelo m�todo soma do objeto calculo. Nesse caso se o resultado for 30 ent�o o teste foi bem sucedido.

Figura 7: Teste aprovado

Na imagem anterior � poss�vel ver o teste sendo realizado, que aparece como aprovado. Isto � poss�vel depois de ter implementado a classe Calculo, que est� abaixo, caso contr�rio, erros ocorreriam. Se fizermos modificaç�es propositais para verificar se est� OK, podemos obter erro, por exemplo, a soma de 10 mais 20 sendo igual a 40.

Figura 8: Passos aprovados e um com erro

Aqui temos tr�s testes como aprovados e um como incorreto, ou seja, 75% dos testes foram bem sucedidos.

Aqui temos a classe Calculo, desenvolvida de forma simples, apenas para a implementaç�o das funcionalidades desejadas. Se a codificaç�o possuir algum erro de funcionalidade, o JUnit vai exibir uma mensagem de erro.

public class Calculo {
      public static int Soma(int a, int b){
        int res=a+b;
        return res;
    }

    static int Subtracao(int a, int b) {
         int res=a-b;
        return res;
    }

    static int Multiplicacao(int a, int b) {
         int res=a*b;
        return res;
    }
    static float Divisao(float a, float b) {
         float res=a/b;
        return res;
    }    
}

Listagem 2. Classe calculo

Anotaç�es do JUnit 4.x

As anotaç�es indicam a funcionalidade do m�todo para o framework, segue uma lista sucinta das anotaç�es do JUnit 4.

@Teste: Identifica que o m�todo � um teste;

@Before: Indica que o m�todo deve ser executado antes do teste, pode ser utilizado para preparar o ambiente de teste;

@After: Indica que o m�todo deve ser executado depois de cada teste, pode ser utilizado para limpar o ambiente de teste;

@BeforeClass: Indica que o m�todo ser� executado antes do in�cio do ensaio;

@AfterClass: Indica que o m�todo ser� executado ao finalizar o ensaio.

Assert do JUnit 4.x

As asserç�es s�o m�todos de ensaio que possibilitam a validaç�o do teste. A lista a seguir contem algumas asserç�es.

fail(String): Deixa o m�todo falhar, normalmente utilizado para verificar se uma determinada parte do c�digo n�o esta sendo atingido;

assertTrue(true)/(false): Ser� sempre verdadeiro ou falso, pode ser utilizado para pr�-definir um resultado de um teste, se o teste ainda n�o foi implementado;

assertEquals(mensagem, esperado, real): Testa dois valores verificando se s�o iguais.

assertEquals(mensagem, esperado, toler�ncia, real): Teste de valores do tipo double ou float, a toler�ncia, neste caso, � o numero de casas decimais que deve ser validado;

assertNull(mensagem, objeto): Verifica se o objeto � nulo;

assertNotNull(mensagem, objeto): Verifica se o objeto n�o � nulo;

assertSame(String, esperado, real): Verifica se as duas vari�veis se referem ao mesmo objeto;

assertNotSame(String, esperado, real): Verifica se as duas vari�veis se refere a objetos diferentes;

Com base nas asserç�es acima, � poss�vel criar diversos testes com o JUnit.

Benef�cios em iniciar o desenvolvimento pelo teste

Em primeiro lugar, quando � criado o teste, normalmente quer dizer que foi entendido o que � para se desenvolver. No exemplo anterior, queremos um objeto que tenha m�todos para realizar soma de dois n�meros, multiplicaç�o, etc. Ent�o podemos testar os retornos, garantindo a qualidade da funcionalidade. Outro beneficio � a reduç�o de problemas, pois j� foram testadas as unidades do sistema. Claro que temos que testar ainda a integraç�o e a aceitaç�o, mas o primeiro passo foi dado para o sucesso do produto.

Alem disso, � apresentado o tempo que levou para serem realizados os testes, desta forma, � poss�vel ainda fazer uma an�lise para a refatoraç�o, ou seja, o processo de melhoria da unidade atrav�s de melhor codificaç�o.

Conclus�es

Esta foi a uma breve introduç�o ao TDD e ao JUnit buscando tratar as informaç�es de forma pr�tica e simples.

Lembre-se: o desenvolvimento guiado por teste � um dos fatores de sucesso na criaç�o de sistemas sustent�veis e com baixa incid�ncia de problemas.

Veni, vidi, codi (Vim, vi e codifiquei)

Refer�ncias

P�gina principal do JUnit
P�gina principal do Netbeans
TDD Desenvolvimento Guiado por Teste - Livro TDD pela vis�o de Kent Beck