Durante a série de artigos sobre TDD, tenho citado o uso de frameworks de testes unitários baseados na JUnit. Os exemplos que serão exibidos durante a série partem do princípio que o leitor conhece o funcionamento de um framework xUnit.
Sendo assim, coloco aqui uma explicação breve sobre a estrutura da maioria destes frameworks, de forma a facilitar o entendimento dos próximos artigos.
Os chamados frameworks xUnit surgiram do framework
SUnit, construído para a linguagem
Smalltalk, por
Kent Beck e
Erich Gamma. A partir daí, o framework foi portado para diversas linguagens (é praticamente certa a existência de um framework para
a sua linguagem favorita) e sua adoção cresceu exponencialmente, sobretudo por projetos que adotaram TDD (como a maioria dos projetos XP).
IdéiaA idéia do framework é facilitar a criação, agrupamento e execução de
testes unitários, permitindo sua automatização e a aplicação de seus conceitos. Como seu uso, podemos executar, de uma só vez, os seguintes testes:
- Teste unitário: verifica se cada pequena parte do programa funciona corretamente.
- Teste de integração: verifica se as partes do programa funcionam corretamente quando utilizadas conjuntamente.
- Teste de regressão: verifica se uma alteração numa parte do programa afeta o funcionamento de outras partes, inclusive as não relacionadas diretamente.
Ao permitir executar estes testes de forma simples e rápida, sua adoção como parte do processo de construção do programa se torna indolor. Por exemplo, a execução dos testes pode ser feita após cada linkagem do programa, de forma automática, bastando configurar a ferramenta que gerencia o processo de compilação e linkagem para executar os testes ao final.
Com isso refatoração de partes do código se torna muito mais segura e quaisquer falhas no código são detectadas imediatamente, dando um
feedback rápido para o desenvolvedor.
Funcionamento BásicoUm projeto de testes baseado na xUnit, poderá exibir sua saída em modo gráfico ou em modo texto, dependo de sua implementação padrão. A maioria gera saída em modo texto, mas em quase todos existem implementações de saídas em modo gráfico que podem ser adquiridas gratuitamente pela Internet.
O framework funciona a partir da criação de um
grupo de testes e da execução dos testes nele contidos. Dentro deste grupo de testes, é permitido adicionar, além dos testes, outros grupos. Ao disparar o método que executa os testes contidos em um grupo, ele executará seus testes e solicitará aos seus subgrupos que também executem seus próprios testes. Assim, todos os testes da hierarquia serão executados. No ponto de entrada do programa, como uma função
main, geralmente haverá um grupo de testes principal que iniciará todo o processo.
Como funciona um testeCada teste criado deve fazer uma verificação sobre o estado ou comportamento de um determinado código. Nas
xUnits, essa verificação é feita utilizando métodos ou macros do tipo
assert, que, em sua maioria, recebem uma variável booleana como parâmetro e lançam uma exceção caso o valor da variável seja falso. A exceção dá informações adicionais, como o número e o conteúdo da linha de código onde estava sendo chamado o
assert. Por exemplo:
assert( 1 > 2 );
Como o resultado da condição é false, uma exceção é lançada informando algo como
"Exceção lançada na linha 1. Condição não cumprida: 1 > 2".
Cada método deverá verificar
uma e só uma funcionalidade, que poderá compreender em um ou mais asserts. Por exemplo:
void CalculaMaiorDeDoisCorretamente()
{
assert( 2 == MaiorDeDois( 1, 2 ) );
assert( 0 == MaiorDeDois( 0, 0 ) );
assert( -1 == MaiorDeDois( -1, -2 ) );
}
O teste verifica se a função
MaiorDeDois funciona com esperado. Caso algum
assert falhe, é exibida a linha de código com a expressão que falhou, como descrito no exemplo anterior.
Originalmente, em praticamente todas as linguagens, um
assert interrompe a execução do programa gerando um erro, que decreve a condição não cumprida. Para que o
assert não funcione desta maneira, os frameworks geralmente criam um novo
assert, como sendo um
método da classe de teste a qual herdamos. Esta lança uma exceção ao invés de interromper a execução do programa.
Onde são colocados os testes
Cada teste deve ser colocado em um grupo de testes, que é chamado formalmente de
Suíte de Testes (Test Suit). Geralmente nos frameworks
xUnit, existe uma classe chamada
TestSuit que será como uma lista de (ponteiros para) métodos de teste que você escreverá.
Você deverá adicionar (o endereço de) cada método de teste que você escrever à um objeto de
TestSuit. Posteriormente, ela poderá executar todos os métodos que você adicionou - um após o outro. Havendo algum
assert dentro deles que não teve sua condição satisfeita, o programa termina com uma exceção (conforme descrito acima).
Na verdade, os métodos que você criou não poderão ser adicionados diretamente no TestSuite. Ao invés disso, você deve criar um objeto de uma classe chamada TestCaller (a "chamadora do teste") que terá o nome do teste e um ponteiro para (o endereço d)ele. Algo como:
TestCaller< MinhaClasseTeste > *chamadaTeste =
new TestCaller< MinhaClasseTeste >(
"NomeDoSeuMetodoDeTeste",
&NomeDoSeuMetodoDeTeste
);
Para simplificar este código, é preferível declarar um tipo que mapeie o TestCaller ao tipo de nossa classe:
typedef TestCaller< MinhaClasseTeste > Chamada;
Agora, substituindo no código anterior, fica:
Chamada *chamadaTeste = new Chamada(
"NomeDoSeuMetodoDeTeste", &NomeDoSeuMetodoDeTeste
);
Agora, para criarmos nossa Suíte de Testes, faremos:
Test* MinhaClasseTeste::suite()
{
Test *suite = new TestSuite( "MinhaClasseTeste" );
Chamada *chamadaTeste = new Chamada(
"NomeDoSeuMetodoDeTeste", &NomeDoSeuMetodoDeTeste
);
suite->addTest( chamadaTeste );
// Ou adiciona diretamente, como neste outro metodo
suite->addTest( new Chamada(
"MeuOutroMetodoDeTeste", &MeuOutroMetodoDeTeste
) );
return ( suite );
}
Existe uma classe chamada
TestCase, que agrupa logicamente testes que verificam o comportamento de uma determinada funcionalidade. Ela possui um construtor que recebe uma string que representa o nome do caso de teste, para facilitar sua identificação, os métodos
setUp e
tearDown para implementação de
fixtures, além de um método estático (para quem não conhece métodos estáticos, pense somente como se fosse um método que você pode acessar sem precisar instanciar um objeto da classe) chamado
suite, que retorna um (objeto de)
TestSuite - o objeto que conterá os nossos testes.
Quando precisarmos criar nossos testes, podemos criar uma classe filha de
TestCase. Ela conterá todo o comportamento necessário para a execução de testes e nossos métodos de teste, com seus
asserts.
Exemplo práticoAssim, para criar um novo caso de teste chamado
TesteContaBancaria, faremos:
- A declaração da classe como filha de TestCase;
- A declaração nossos testes, preferencialmente na parte privada da classe, pois os mesmos não serão acessados por outras classes;
- A implementação dos testes;
- A implementação de um método estático suite que criará um TestSuite e adicionará à ele (o endereço de) todos os nossos testes;
Os métodos
setUp e
tearDown não precisam ser implementados, a menos que você precise fazer um
fixture (que veremos mais tarde).
class TesteContaBancaria : public TestCase
{
public:
TesteContaBancaria(std::string nome);
// Suite de testes
static Test* suite();
private:
// Metodo de teste
void ContaTransfereCorretamente();
};
TesteContaBancaria::TesteContaBancaria(
std::string nome
) : TestCase( nome ) // Chama o construtor de TestCase
{
}
Test* TesteContaBancaria::suite()
{
// Cria a suite de testes
Test *suite = new TestSuite( "TesteContaBancaria" );
typedef TestCaller< TesteContaBancaria > Chamada;
// Adiciona o metodo ContaTransfereCorretamente para
// ser chamado pela suite
suite->Add( new Chamada(
&ContaTransfereCorretamente,
"ContaTransfereCorretamente"
));
return ( suite );
}
void TesteContaBancaria::ContaTransfereCorretamente()
{
ContaBancaria minhaConta, suaConta;
minhaConta.DefinirSaldo( 1000.00 );
suaConta.DefinirSaldo( 0.00 );
minhaConta.Transferir( suaConta, 400.00 );
CHECK_EQUALS( 400.00, suaConta.Saldo() );
CHECK_EQUALS( 600.00, minhaConta.Saldo() );
}
Obs: A macro
CHECK_EQUALS aqui foi criada sobre
assert, e recebe o valor esperado e o valor atual. Se os valores diferirem, uma exceção será lançada. Existem diversas outras macros disponíveis para auxiliar na verificação de estados, dependendo da linguagem utilizada.
Repare que o método de teste
ContaTransfereCorretamente é privado. Isto se deve ao fato que ele nunca será acessado diretamente fora da classe e também não se espera que a classe de teste tenha filhas, que irão chamar o método diretamente. Assim, costuma ser um padrão de TDD colocar os métodos de teste como sendo privados.
Este é o funcionamento básico de um framework xUnit. Na parte 2 irei expor o uso de
fixtures e mostrarei outros métodos/macros úteis para as verificações de estado. Até lá.
