NUnit: O Framework para Testes Unit�rios do Microsoft .NET

Por que eu devo ler este artigo:Este artigo aborda o tema teste unit�rio com o objetivo de mostrar como o desenvolvedor pode us�-lo para testar o c�digo-fonte de suas aplicaç�es. Neste sentido, o artigo prov� conhecimento ao desenvolvedor sobre como implementar casos de teste unit�rios utilizando NUnit atrav�s de exemplos pr�ticos.

O tema se torna fundamental para desenvolvedores que buscam cada vez mais melhorar suas aplicaç�es ao adotarem pol�ticas de teste. Essa tarefa ser� apoiada pelo conhecimento adquirido aqui sobre construç�o de casos de testes unit�rios usando NUnit.

O objetivo deste artigo � fornecer conhecimento pr�tico para desenvolvedores que buscam aprender sobre teste unit�rio de software utilizando NUnit. Neste artigo ser�o apresentadas as teorias importantes que envolvem a construç�o de testes unit�rios, bem como um exemplo simples e inicial para visualizar a aplicaç�o de tais conceitos.

Saiba mais: Teste unit�rio: Descubra erros no c�digo antes que ele falhe!

Ao longo dos tempos v�rias literaturas t�cnicas diferentes v�m abordando o tema teste unit�rio de software. A import�ncia da realizaç�o de testes � propagada e defendida por v�rios autores. V�rias t�cnicas para teste unit�rio de software v�m sendo utilizadas por diversos desenvolvedores, que cada vez mais buscam aprender sobre estas t�cnicas e como utiliz�-las. Existem diferentes tipos de testes e diferentes tecnologias que ap�iam sua utilizaç�o.

Nesse sentido, o objetivo deste artigo � fornecer conhecimento pr�tico para desenvolvedores que buscam aprender sobre teste unit�rio de software utilizando NUnit. Neste artigo ser�o apresentadas as teorias importantes que envolvem a construç�o de testes unit�rios, bem como um exemplo simples e inicial para visualizar a aplicaç�o de tais conceitos.

Um primeiro exemplo consiste na apresentaç�o de um m�todo a ser testado e como escrever c�digo de teste para test�-lo. Posteriormente, ser� apresentado outro exemplo, com um n�vel de dificuldade maior, com o intuito de demonstrar como � a implementaç�o de c�digo de teste antes mesmo da exist�ncia do m�todo a ser testado, o que � descrito em algumas literaturas t�cnicas como sendo o ideal. A ideia � implementar o c�digo de teste com base nas informaç�es que se conhece sobre o software que ser� desenvolvido. Ap�s a concepç�o do c�digo de teste, ser� poss�vel implementar a aplicaç�o e, em paralelo, executar os testes anteriormente escritos, permitindo que a aplicaç�o passe por um ciclo de desenvolvimento e teste.

Outro importante objetivo deste artigo � demonstrar de forma pr�tica como se d� o processo de manutenç�o em um trecho de c�digo, no caso um m�todo, garantindo que as alteraç�es feitas n�o eliminaram nenhuma funcionalidade do mesmo. Isto ser� garantido pela execuç�o dos testes antes e depois da manutenç�o ter sido realizada.

Ao final, espera-se que o desenvolvedor seja capaz de entender as teorias importantes que devem ser consideradas para a escrita de c�digo de teste, seja capaz de escrever c�digo de teste para m�todos existentes, escrever c�digo de teste antes mesmo do m�todo a ser testado existir, e seja capaz de realizar manutenç�es em m�todos de aplicaç�es que j� est�o em uso, garantindo atrav�s da execuç�o de testes, que as manutenç�es n�o comprometeram o m�todo mantido.

NUnit, um framework livre para testes

O NUnit � um framework livre para testes unit�rios. Com o NUnit � poss�vel criar casos de teste unit�rios no Visual Studio e execut�-los, obtendo o resultado (uma das formas) em um aplicativo gr�fico que permite a visualizaç�o simplificada do sucesso ou fracasso dos testes executados.

Neste artigo o desenvolvedor ser� capaz de entender como utilizar de forma pr�tica os recursos do NUnit, entendendo desde o processo de instalaç�o, at� a escrita de casos de teste, que s�o m�todos implementados para testar m�todos de uma aplicaç�o.

Utilizando o NUnit no Visual Studio 2008

O primeiro passo para a utilizaç�o do NUnit dentro do Visual Studio � fazer o download do framework NUnit no site (ver seç�o Links). A vers�o a ser utilizada � a 2.5.10, para Windows. Feito o download, � necess�rio a instalaç�o do execut�vel.

O processo de instalaç�o � simples. Ap�s iniciada a instalaç�o, o pr�ximo passo consiste em ler e aceitar os termos de uso e avançar.

� poss�vel alterar algumas configuraç�es da instalaç�o utilizando a instalaç�o personalizada, inclusive o local da instalaç�o, que por padr�o � na pasta Arquivos de Programas. Em seguida � iniciada a instalaç�o, quando o NUnit estar� pronto para ser utilizado.

Um aplicativo que permite a execuç�o de casos de teste previamente escritos no Visual Studio foi instalado no computador (Figura 1). Acessando o menu File � poss�vel adicionar um projeto do Visual Studio que contenha casos de teste para que os testes possam ser executados. O Bot�o Run, e a barra abaixo do bot�o ser�o utilizados para executar e exibir o processo de execuç�o dos casos de teste. A partir deste momento, o Visual Studio e o computador est�o prontos para trabalharem com testes unit�rios.

Figura 1. Aplicativo NUnit.

Criando e executando casos de teste com NUnit

O primeiro exemplo a ser utilizado � bem simples. Consiste em testar um m�todo que verifica se um par�metro recebido est� vazio ou n�o, retornando um valor booleano que indicar� true para par�metro de tamanho maior que zero (em n�mero de caracteres, por se tratar de String) ou false, caso contr�rio. O m�todo a ser testado � chamado de verificarCampoVazio, e pertence � classe FormularioSimples, que herda de Form, por se tratar de uma classe atrelada a uma interface. Ao clicar no bot�o Salvar do formul�rio, � invocado um m�todo que verifica se um textbox est� vazio. A Listagem 1 mostra a classe FormularioSimples contendo o evento do bot�o Salvar, linhas 7 a 14, e o m�todo verificarCampoVazio, linhas 15 a 25.

Listagem 1. Classe FormularioSimples


  1.  public partial class FormularioSimples : Form
  2.  {
  3.     public FormularioSimples()
  4.     {
  5.         InitializeComponent();
  6.     }
  7.     private void buttonSalvar_Click(object sender, EventArgs e)
  8.     {
  9.         String campo = textBoxNome.Text;
  10.        if(verificarCampoVazio(campo)== false)
  11.        {
  12.             MessageBox.Show("Campo Vazio");
  13.        }
  14.    }
  15.    public Boolean verificarCampoVazio(String campo)
  16.    {
  17.        if (campo.Length > 0)
  18.        {
  19.            return true;
  20.        }
  21.        else
  22.        {
  23.             return false;
  24.        }
  25.     }
  26.     }

O pr�ximo passo � definir o caso de teste que ser� utilizado para testar o m�todo verificarCampoVazio. Para essa tarefa, � definida uma classe que ficar� respons�vel por carregar os casos de teste que se aplicam � classe que ela representa, no caso, a classe a ser criada � TFormularioSimples, que receber� os casos de teste de todos os m�todos da classe FormularioSimples que se desejar testar. Nesse exemplo, apenas o m�todo verificarCampoVazio da classe FormularioSimples ser� testado. A classe TFormularioSimples recebe o mesmo nome da classe que representa, com o acr�scimo da letra �T�, que servir� para indicar que se trata de uma classe de teste, assim como �I� � usado para mostrar que se trata de uma interface de uma classe. A Listagem 2 mostra a classe TFormularioSimples.

Listagem2. Classe TFormularioSimples.


  1.  public class TFormularioSimples
  2.  {
  3.  }

A classe criada deve agora poder receber um caso de teste para testar o m�todo verificarCampoVazio. Para que isso seja poss�vel, deve-se adicionar ao projeto a refer�ncia ao NUnit, com o bot�o direito sobre o projeto no Solution Explorer, acessando Adicionar refer�ncia, como mostra a Figura 2.

Figura 2. Adicionando refer�ncia.

Feito isso, busca-se pela refer�ncia chamada nunit.framework, como mostra a Figura 3.

Figura 3. Buscando a refer�ncia do NUnit.

O projeto j� contem uma refer�ncia ao NUnit (Figura 4).

Figura 4. Refer�ncia do NUnit.

Para que a classe TFormularioSimples possa utilizar os recursos da refer�ncia adicionada, deve-se inserir na classe a refer�ncia ao namespace do NUnit, como pode ser visto na Listagem 3, linha 5.

Listagem 3. Classe TFormularioSimples.


  1.  using System;
  2.  using System.Collections.Generic;
  3.  using System.Linq;
  4.  using System.Text;
  5.  using NUnit.Framework;
  6.  namespace Projeto01
  7.  {
  8.     public class TFormularioSimples
  9.     {
  10.    }
  11. }

O pr�ximo passo consiste na criaç�o dos m�todos de teste que servir�o para testar o m�todo verificarCampoVazio. A Listagem 4 mostra os m�todos de teste criados.

Listagem 4. Classe TFormularioSimples.


  1.  using System;
  2.  using System.Collections.Generic;
  3.  using System.Linq;
  4.  using System.Text;
  5.  using NUnit.Framework;
  6.  namespace Projeto01
  7.  {
  8.      [TestFixture]
  9.      public class TFormularioSimples
  10.     {
  11.           private FormularioSimples formulario = new FormularioSimples();
  12.           [Test]
  13.           public void testarVerificarCampoVazio1()
  14.           {
  15.                Boolean resultado = formulario.verificarCampoVazio("");
  16.                Assert.AreEqual(false, resultado);
  17.           }
  18.           [Test]
  19.           public void testarVerificarCampoVazio2()
  20.           {
  21.               Boolean resultado = formulario.verificarCampoVazio("Jacimar Tavares");
  22.               Assert.AreEqual(true, resultado);
  23.           }
  24.      }
  25.     }

O c�digo da Listagem 4 contem, primeiramente, a refer�ncia ao NUnit (linha 5). TextFixture (linha 8) � a indicaç�o de que a classe abaixo � uma classe que cont�m casos de teste. A declaraç�o da classe na linha 9 possui nome id�ntico ao da classe que cont�m o m�todo a ser testado (Listagem 1) acrescido do prefixo �T�. Test (linha 12) � utilizado para fazer com que o m�todo que vem abaixo se torne um m�todo de teste. O mesmo pode ser visto na linha 18, o que torna o m�todo da linha 19 um m�todo de teste.

A classe de teste da Listagem 4 possui dois m�todos de teste, pois o m�todo a ser testado, verificarCampoVazio, linha 15 a 25 da Listagem 1, pode retornar dois diferentes tipos de informaç�o, dependendo do tipo de informaç�o passada a ele por par�metro.

Na linha 11 da Listagem 4 tem-se a instanciaç�o de um objeto da classe FormularioSimples, que permitir� o acesso, atrav�s do objeto instanciado, ao m�todo a ser testado.

O primeiro m�todo de teste da classe de teste TFormularioSimples, linhas 12 a 17 da Listagem 4, foi nomeado testarCampoVazio1, onde o n�mero 1 � utilizado para indicar que esse � o primeiro dos casos de teste do m�todo a ser testado. A utilizaç�o do n�mero n�o � regra. Aqui � usado para indicar que se trata do primeiro m�todo de teste apenas. O corpo do m�todo possui a declaraç�o de uma vari�vel booleana de nome resultado que receber� o retorno do m�todo a ser testado. Em seguida, � utilizado o m�todo AreEqual da classe Assert (linha 16 da Listagem 4). Como par�metro � passado o valor esperado e o valor que deve ser usado para comparar se o valor esperado � igual ao valor obtido. No caso, o valor armazenado na vari�vel resultado. Se o valor esperado for igual ao valor obtido, quer dizer que o teste funcionou. Se o resultado for diferente, indica que h� algo errado com o m�todo que est� sendo testado.

Neste momento os testes se encontram prontos para serem executados. O primeiro passo para a execuç�o dos casos de teste � a compilaç�o do projeto. Se o projeto que recebe a classe de teste n�o for compilado, n�o ser� poss�vel prosseguir. Compilada a aplicaç�o, � chegado o momento de executar os testes. Ao iniciar o aplicativo do NUnit (menu iniciar/ NUnit 2.5.10) deve-se adicionar o projeto do Visual Studio (.exe do projeto) no NUnit. Para isso, basta acessar o menu File e Open Project. Busca-se pelo .exe do projeto do Visual Studio. A Figura 5 mostra o projeto adicionado na ferramenta do NUnit.

Figura 5. Projeto adicionado ao NUnit.

Na Figura 5 � poss�vel perceber que o projeto adicionado possui uma classe de teste, exatamente como no projeto do Visual Studio. Ao adicionar o execut�vel do projeto, automaticamente o NUnit identifica quais classes cont�m m�todos de teste e quais s�o esses m�todos. A classe TFormularioSimples possui dois m�todos de teste, assim como foi implementado na Listagem 4. Ao selecionar e executar o m�todo de teste testarVerificarCampoVazio1, a barra abaixo do bot�o run deve ficar verde, indicando que o m�todo passou no teste, como pode ser visto na Figura 6.

Figura 6. Teste 1 executado com sucesso.

O mesmo procedimento deve ser feito com o segundo m�todo de teste, que tamb�m deve passar, como pode ser visto na Figura 7.

Figura 7. Teste 2 executado com sucesso.

Os casos de teste passaram, e isto indica que o m�todo verificarCampoVazio funciona como se esperava. Se um dos m�todos de teste for alterado, como por exemplo, trocar o valor que se espera do teste, o teste certamente falhar�. Para isso, considere a Listagem 5.

Listagem 5. C�digo m�todo de teste 1.


  1.  ...
  2.  [Test]
  3.  public void testarVerificarCampoVazio1()
  4.  {
  5.       Boolean resultado = formulario.verificarCampoVazio("");
  6.       Assert.AreEqual(true, resultado);
  7.  }
  8.  ...

Na Listagem 5, linha 6, � poss�vel perceber que o m�todo de teste testarVerificarCampoVazio1 teve o valor esperado alterado. Agora se espera que o m�todo retorne true ao inv�s de false. Como o m�todo a ser testado est� implementado de forma correta, ele retornar� false e, portanto o teste falhar�. A Figura 8 mostra o teste ap�s as mudanças da Listagem 5.

Figura 8. Teste 1 falhando.

Na Figura 8 � poss�vel verificar na mensagem o motivo do erro, que define que o m�todo de teste estava esperando True, mas foi retornado False. O exemplo apresentado, apesar de testar um m�todo simples, serviu para ilustrar como � a escrita e o funcionamento de um caso de teste.

Algumas literaturas t�cnicas sobre teste de software sugerem que os casos de teste sejam definidos antes mesmo do m�todo a ser testado. Isto permitir� que o m�todo a ser testado j� seja pass�vel de teste desde a sua concepç�o. Al�m disso, a criaç�o do teste antes do m�todo a ser testado permite que o m�todo seja implementado e testado assim que uma �primeira vers�o� do m�todo surgir. Caso todos os testes sejam bem sucedidos, significar� que o m�todo j� est� pronto e devidamente implementado. Outro benef�cio est� ligado � capacidade que algumas equipes t�m de trabalhar com tarefas e funç�es distribu�das. Um membro da equipe pode assumir a tarefa de desenvolver o c�digo da aplicaç�o com base nas informaç�es que possui sobre ela (uma especificaç�o do sistema, por exemplo), enquanto isso, outro membro da equipe pode assumir o papel do testador e, de posse da mesma especificaç�o, desenvolver o c�digo de teste antes mesmo de conhecer o resultado do trabalho do desenvolvedor. Ao final, o testador executaria os testes que ele escreveu no c�digo que o desenvolvedor implementou.

A partir de agora ser� considerado o seguinte cen�rio: surgiu a necessidade de se implementar um aplicativo que calcule o novo valor de uma prestaç�o com base em algumas informaç�es. Toda prestaç�o a ser paga, no ato do pagamento, deve ser revisada. Isso implica em dar desconto para prestaç�es que est�o sendo pagas antes do vencimento e cobrar juros de prestaç�es pagas depois da data de vencimento. Nesse sentido, sabe-se que ser� preciso calcular o novo valor da parcela. � interessante que o aplicativo tenha um m�todo que calcule este novo valor de parcela. Parcelas pagas antes da data de vencimento devem ter desconto de R$ 7,25. Parcelas pagas depois da data de vencimento devem ter um acr�scimo de R$ 2,38 em forma de multa. Percebe-se que existem dois problemas a serem implementados. Um se resume na tarefa de descobrir se a prestaç�o a ser paga, dada sua data de vencimento, j� est� vencida. A outra tarefa � calcular o desconto ou juro, caso a prestaç�o esteja vencida ou n�o.

Mediante essas informaç�es, deve-se se certificar de que, a toda data de vencimento inserida na aplicaç�o, deve-se descobrir se j� venceu. Depois disso, deve-se certificar que o c�lculo do desconto, ou da multa, est� sendo feito corretamente mediante a informaç�o descoberta sobre o vencimento da prestaç�o. Isso leva � definiç�o de dois m�todos: descobrirSePrestacaoVenceu e outro m�todo chamado calcularNovoValorPrestacao. A Listagem 6 mostra a classe Prestacao com a definiç�o dos dois m�todos.

Listagem 6. Classe Prestacao


  1.  public class Prestacao
  2.  {
  3.       public Decimal calcularNovoValorParcela(DateTime dataVencimento, Decimal valorParcela)
  4.       {
  5.           return 0;
  6.       }
  7.       public Boolean descobrirSePrestacaoVenceu(DateTime dataVencimento)
  8.       {
  9.           return false;
  10.      }
  11. }

O primeiro m�todo, linhas 3 a 6 da Listagem 6, mostra a definiç�o do m�todo que calcular� o novo valor da prestaç�o. As linhas 7 a 10 cont�m o m�todo que ser� o respons�vel por descobrir se a prestaç�o j� venceu. O objetivo de definir dois m�todos, e n�o apenas um que faça tudo, � a divis�o de responsabilidades, devido ao fato de que cada m�todo deve desempenhar apenas uma funç�o para que a faça bem e n�o carregue mais responsabilidades do que deveria, e tamb�m para facilitar a concepç�o de testes, pois cada uma das funcionalidades ser� testada individualmente.

A ideia � fazer com que, dada a data de vencimento e o valor da parcela ao m�todo calcularNovoValorParcela, ele descubra, ao invocar o m�todo descobrirSePrestacaoVenceu, se a parcela venceu e s� depois disso realize sua funç�o que � calcular o desconto ou a multa. Antes que os dois m�todos sejam desenvolvidos ser�o implementados os testes para, na medida em que as primeiras vers�es dos m�todos forem saindo, os testes sejam executados.

Primeiramente define-se a classe de teste que receber� os casos de teste. A Listagem 7 mostra a classe criada.

Listagem 7. Classe TPrestacao


  1.  using System;
  2.  using System.Collections.Generic;
  3.  using System.Linq;
  4.  using System.Text;
  5.  using NUnit.Framework;
   
  6.  namespace Projeto02
  7.  {
  8.     [TestFixture]
  9.     public class TPrestacao: Prestacao
  10.    {
  11.  
  12.    }

Vale lembrar que para se criar uma classe de teste, primeiramente deve-se inserir a refer�ncia ao nunit.framework, e us�-la na classe. Nesse momento deve-se definir os casos de teste para o m�todo descobrirSePrestacaoVenceu, visto que ele ser� utilizado pelo outro m�todo de c�lculo de parcela. J� se sabe que o m�todo descobrirSePrestacaoVenceu recebe por par�metro a data de vencimento da prestaç�o. Obviamente, para saber se a prestaç�o venceu, deve-se compar�-la com a data atual. Nesse momento deve-se definir as datas que ser�o utilizadas como data de vencimento, e somente depois implementar casos de teste que executem testes com essas datas. Para isto, considera-se que a data atual � 28/10/2011. Sendo assim, as datas que ser�o utilizadas para teste devem ser anteriores, iguais e maiores que a data atual.

A etapa de definir quais argumentos ser�o utilizados para testar o m�todo que ainda n�o foi implementado � uma das mais complexas, pois se o m�todo ainda n�o foi implementado, n�o se conhece a sua complexidade ciclom�tica, o que auxilia na definiç�o do n�mero de casos de teste. Se n�o se definir todas as datas que far�o com que o m�todo possa ser testado de forma correta, corre-se o risco de o teste n�o identificar todos os caminhos que o m�todo pode tomar, mediante diferentes entradas. Os casos de teste implementados para estas datas podem ser vistos na Listagem 8.

Listagem 8. Classe TPrestacao


  1.  using System;
  2.  using System.Collections.Generic;
  3.  using System.Linq;
  4.  using System.Text;
  5.  using NUnit.Framework;
  6.  namespace Projeto02
  7.  {
  8.      [TestFixture]
  9.      public class TPrestacao: Prestacao
  10.     {
  11.        [Test]
  12.        public void testeDescobrirSePrestacaoVenceu1()
  13.        {
  14.           DateTime dataVencimento1 = new DateTime(2010, DateTime.Today.Month, DateTime.Today.Day);
  15.           Boolean resultado = descobrirSePrestacaoVenceu(dataVencimento1);
  16.           Assert.AreEqual(true,resultado);
  17.        }
  18.        [Test]
  19.        public void testeDescobrirSePrestacaoVenceu2()
  20.        {
  21.           DateTime dataVencimento2 = new DateTime(2011, DateTime.Today.Month, DateTime.Today.Day);
  22.           Boolean resultado = descobrirSePrestacaoVenceu(dataVencimento2);
  23.           Assert.AreEqual(false, resultado);
  24.        }
  25.       [Test]
  26.       public void testeDescobrirSePrestacaoVenceu3()
  27.       {
  28.           DateTime dataVencimento3 = new DateTime(2012, DateTime.Today.Month, DateTime.Today.Day);
  29.           Boolean resultado = descobrirSePrestacaoVenceu(dataVencimento3);
  30.           Assert.AreEqual(false, resultado);
  31.       }
  32.       [Test]
  33.       public void testeDescobrirSePrestacaoVenceu4()
  34.       {
  35.           DateTime dataVencimento4 = new DateTime(DateTime.Today.Year, 09, DateTime.Today.Day);
  36.           Boolean resultado = descobrirSePrestacaoVenceu(dataVencimento4);
  37.           Assert.AreEqual(true, resultado);
  38.       }
  39.       [Test]
  40.       public void testeDescobrirSePrestacaoVenceu5()
  41.       {
  42.           DateTime dataVencimento5 = new DateTime(DateTime.Today.Year, 11, DateTime.Today.Day);
  43.           Boolean resultado = descobrirSePrestacaoVenceu(dataVencimento5);
  44.           Assert.AreEqual(false, resultado);
  45.       }
  46.       [Test]
  47.       public void testeDescobrirSePrestacaoVenceu6()
  48.       {
  49.            DateTime dataVencimento6 = new DateTime(DateTime.Today.Year, DateTime.Today.Month, 27);
  50.            Boolean resultado = descobrirSePrestacaoVenceu(dataVencimento6);
  51.            Assert.AreEqual(true, resultado);
  52.       }
  53.       [Test]
  54.       public void testeDescobrirSePrestacaoVenceu7()
  55.       {
  56.            DateTime dataVencimento7 = new DateTime(DateTime.Today.Year, DateTime.Today.Month, 29);
  57.            Boolean resultado = descobrirSePrestacaoVenceu(dataVencimento7);
  58.            Assert.AreEqual(false, resultado);
  59.       }
  60.    }
  61. }

O m�todo das linhas 11 a 17 executa um teste com a data 28/10/2010, j� o m�todo das linhas 18 a 24 com a data 28/10/2011. Linhas 25 a 31, a data 28/10/2012, linhas 32 a 38 a data 28/09/2011, linhas 39 a 45 a data 28/11/2011, linhas 46 a 52 a data 27/10/2011 e, por �ltimo, as linhas 53 a 59, com a data 29/10/2011. Essas datas foram selecionadas de forma a realizar comparaç�es de datas em funç�o do dia, m�s e ano, antes e depois da data selecionada. O projeto do Visual Studio deve ser compilado. Se aberto no aplicativo do NUnit, ser� poss�vel visualizar os casos de teste implementados, como mostra a Figura 9.

Figura 9. Casos de teste implementados.

Nesse momento tem-se definido todos os casos de teste necess�rios para o m�todo descobrirSePrestacaoVenceu. O pr�ximo passo � a escrita do corpo do m�todo descobrirSePrestacaoVenceu, por enquanto inexistente (linhas 7 a 10 da Listagem 6). A implementaç�o do m�todo pode ser vista na Listagem 9.

Listagem 9. M�todo descobrirSePrestacaoVenceu implementado


  1.  public Boolean descobrirSePrestacaoVenceu(DateTime dataVencimento)
  2.  {
  3.      DateTime dataAtual = DateTime.Today;
  4.      Int32 anoAtual = dataAtual.Year;
  5.      Int32 anoDataVencimento = dataVencimento.Year;
  6.      Int32 mesAtual = dataAtual.Month;
  7.      Int32 mesVencimento = dataVencimento.Month;
  8.      Int32 diaAtual = dataAtual.Day;
  9.      Int32 diaVencimento = dataVencimento.Day;
  10.     if (anoAtual > anoDataVencimento)
  11.     {
  12.         return true;
  13.     }
  14.     else
  15.     {
  16.         if (mesAtual <= mesVencimento)
  17.         {
  18.             return true;
  19.         }
  20.         else
  21.         {
  22.             if (diaAtual <= diaVencimento)
  23.             {
  24.                 return true;
  25.             }
  26.             else
  27.             {
  28.                 return true;
  29.             }
  30.         }
  31.     }
  32.     }

O m�todo est� implementado, mas ao rodar os testes previamente escritos, alguns erros s�o encontrados, como mostra a Figura 10.

Figura 10. M�todos de teste executados.

Os testes que falharam foram os testes 2, 3 5 e 7. No teste 2, com data de 28/10/2011, esperava-se false, indicando que a prestaç�o n�o venceu, mas o retorno foi true. No teste 3, com data de 28/10/2012, esperava-se false, indicando que a prestaç�o n�o venceu, mas o retorno foi true. Para o teste 5, dada a data 28/11/2011, esperava-se false, indicando que a prestaç�o n�o venceu, mas o retorno foi true. Por �ltimo tem-se o teste 7, que mediante a data de entrada 29/10/2011, esperava-se false, indicando que a prestaç�o n�o venceu, mas o retorno foi true.

Todos estes testes que falharam indicam que o m�todo foi escrito de forma errada. Algo deve ser refeito. O m�todo foi reescrito como uma segunda vers�o. A Listagem 10 mostra o m�todo depois de reescrito.

Listagem 10. M�todo descobrirSePrestacaoVenceu reescrito


  1.  public Boolean descobrirSePrestacaoVenceu(DateTime dataVencimento)
  2.  {
  3.      DateTime dataAtual = DateTime.Today;
  4.      Int32 anoAtual = dataAtual.Year;
  5.      Int32 anoDataVencimento = dataVencimento.Year;
  6.      Int32 mesAtual = dataAtual.Month;
  7.      Int32 mesVencimento = dataVencimento.Month;
  8.      Int32 diaAtual = dataAtual.Day;
  9.      Int32 diaVencimento = dataVencimento.Day;
  10.     if (anoDataVencimento < anoAtual)
  11.     {
  12.         return true;
  13.     }
  14.     else
  15.     {
  16.        if (mesVencimento < mesAtual)
  17.        {
  18.             return true;
  19.        }
  20.        else
  21.        {
  22.            if (diaVencimento < diaAtual)
  23.            {
  24.                 return true;
  25.            }
  26.            else
  27.            {
  28.                return false;
  29.            }
  30.        }
  31.      }
  32.     }

As mudanças foram feitas na l�gica das linhas 16 e 22 da Listagem 10, em relaç�o � Listagem 9, que apresentava o m�todo que n�o passou em todos os testes. Com essas mudanças, depois de rodar os testes, pode-se comprovar que o m�todo descobrirSePrestacaoVenceu est� pronto para testar todo tipo de data, fazendo uma comparaç�o com a data atual que � 28/10/2011 (ver Figura 11).

Figura 11. M�todos de teste executados.

Um problema com os casos de teste escritos � que o teste � feito com alguns valores que foram inseridos de forma manual, para a data atual, que no caso � 28/10/2011, como citado. Entretanto, isso pode ocasionar problemas, se os testes forem executados em outra data, que n�o seja a inserida manualmente. Para resolver esse problema, devem-se considerar as mudanças feitas na Listagem 11, em relaç�o ao mesmo c�digo da Listagem 8. As mudanças podem ser vistas nas linhas 7, 14, 21, 28, 35, 42 e 49.

Listagem 11. M�todos de teste da classe TPrestacao modificados


  1.  [TestFixture]
  2.  public class TPrestacao: Prestacao
  3.  {
  4.     [Test]
  5.      public void testeDescobrirSePrestacaoVenceu1()
  6.      {
  7.         DateTime dataVencimento1 = new DateTime(DateTime.Today.Year - 1,     DateTime.Today.Month, DateTime.Today.Day);
  8.         Boolean resultado = descobrirSePrestacaoVenceu(dataVencimento1);
  9.         Assert.AreEqual(true,resultado);
  10.     }
  11.     [Test]
  12.      public void testeDescobrirSePrestacaoVenceu2()
  13.      {
  14.          DateTime dataVencimento2 = new DateTime(DateTime.Today.Year, DateTime.Today.Month, DateTime.Today.Day);
  15.          Boolean resultado = descobrirSePrestacaoVenceu(dataVencimento2);
  16.          Assert.AreEqual(false, resultado);
  17.      }
  18.      [Test]
  19.      public void testeDescobrirSePrestacaoVenceu3()
  20.      {
  21.          DateTime dataVencimento3 = new DateTime(DateTime.Today.Year + 1,   DateTime.Today.Month, DateTime.Today.Day);
  22.          Boolean resultado = descobrirSePrestacaoVenceu(dataVencimento3);
  23.          Assert.AreEqual(false, resultado);
  24.      }
  25.      [Test]
  26.      public void testeDescobrirSePrestacaoVenceu4()
  27.      {
  28.         DateTime dataVencimento4 = new DateTime(DateTime.Today.Year, DateTime.Today.Month - 1, DateTime.Today.Day);
  29.         Boolean resultado = descobrirSePrestacaoVenceu(dataVencimento4);
  30.         Assert.AreEqual(true, resultado);
  31.      }
   
  32.      [Test]
  33.      public void testeDescobrirSePrestacaoVenceu5()
  34.      {
  35.          DateTime dataVencimento5 = new DateTime(DateTime.Today.Year, DateTime.Today.Month + 1, DateTime.Today.Day);
  36.          Boolean resultado = descobrirSePrestacaoVenceu(dataVencimento5);
  37.          Assert.AreEqual(false, resultado);
  38.      }
  39.      [Test]
  40.      public void testeDescobrirSePrestacaoVenceu6()
  41.      {
  42.          DateTime dataVencimento6 = new DateTime(DateTime.Today.Year,  DateTime.Today.Month, DateTime.Today.Day - 1);
  43.          Boolean resultado = descobrirSePrestacaoVenceu(dataVencimento6);
  44.          Assert.AreEqual(true, resultado);
  45.      }
  46.      [Test]
  47.      public void testeDescobrirSePrestacaoVenceu7()
  48.      {
  49.          DateTime dataVencimento7 = new DateTime(DateTime.Today.Year, DateTime.Today.Month, DateTime.Today.Day + 1);
  50.          Boolean resultado = descobrirSePrestacaoVenceu(dataVencimento7);
  51.          Assert.AreEqual(false, resultado);
  52.      }
  53.   }

No ponto em que o projeto se encontra, o m�todo descobrirSePrestacaoVenceu est� devidamente implementado e testado. O pr�ximo passo � a implementaç�o dos casos de teste referentes ao m�todo calcularNovoValorParcela (ver Listagem 6, linhas 3 a 6).

O m�todo calcularNovoValorParcela, como j� foi dito, deve calcular o valor da nova parcela acrescida de juros, caso j� esteja vencida, ou dar desconto na parcela, caso ainda esteja em dia. Analisando esse contexto, fica evidente que o caso de teste a ser implementado deve esperar um valor acrescido de juros, dada uma data vencida e uma parcela, e em outro teste, esperar uma parcela com desconto, dada uma data de vencimento que ainda n�o aconteceu e uma parcela. Os casos de teste escritos de acordo com estas particularidades podem ser vistos na Listagem 12. Os casos est�o implementados na mesma classe, TPrestacao, que recebeu os outros casos de testes definidos anteriormente para o m�todo descobrirSePrestacaoVenceu.

Listagem 12. Classe TPrestacao


  1.  [TestFixture]
  2.  public class TPrestacao: Prestacao
  3.  {
  4.      ...
  5.      [Test]
  6.      public void testeDescobrirSePrestacaoVenceu7()
  7.      {
  8.          DateTime dataVencimento7 = new DateTime(DateTime.Today.Year,        DateTime.Today.Month, DateTime.Today.Day + 1);//2011/10/29
  9.          Boolean resultado = descobrirSePrestacaoVenceu(dataVencimento7);
  10.         Assert.AreEqual(false, resultado);
  11.     }
  12.     [Test]
  13.     public void testeCalcularNovoValorParcela1()
  14.     {
  15.          DateTime dataVencimento = new DateTime(DateTime.Today.Year, DateTime.Today.Month, DateTime.Today.Day - 1);
  16.          Decimal novaParcela = calcularNovoValorParcela(dataVencimento, 100.00m);
  17.          Assert.AreEqual(102.38m, novaParcela);
  18.     }
   
  19.     [Test]
  20.     public void testeCalcularNovoValorParcela2()
  21.     {
  22.          DateTime dataVencimento = new DateTime(DateTime.Today.Year,          DateTime.Today.Month, DateTime.Today.Day + 1);
  23.          Decimal novaParcela = calcularNovoValorParcela(dataVencimento, 100.00m);
  24.          Assert.AreEqual(92.75m, novaParcela);
  25.     }
  26. }

Nas linhas 12 a 25 da Listagem 12 est�o os m�todos de teste que foram implementados para testar o m�todo calcularNovoValorParcela. O primeiro m�todo de teste, linhas 12 a 18, espera (linha 17) que, ao ser passada a data de vencimento (vencida por um dia) e o valor da parcela que � R$ 100,00 (linha 16), que o m�todo retorne o valor da nova parcela igual a R$ 102,38. J� o segundo m�todo de teste, linhas 19 a 25, passa uma data a vencer no dia seguinte, mais uma parcela no valor de R$ 100,00 esperando que o m�todo retorne o valor de R$ 92,75.

Implementados os m�todos, o pr�ximo passo � a implementaç�o do m�todo calcularNovoValorParcela, que ainda n�o possui c�digo em seu corpo (Listagem 6). A implementaç�o do m�todo pode ser vista na Listagem 13.

Listagem 13. Classe Prestacao


  1.  public class Prestacao
  2.  {
  3.        ...
  4.        public Decimal calcularNovoValorParcela(DateTime dataVencimento, Decimal valorParcela)
  5.        {
  6.             if (descobrirSePrestacaoVenceu(dataVencimento))
  7.             {
  8.                 Decimal multa = 2.38m;
  9.                 Decimal valorParcelaCorrigida = valorParcela + multa;
  10.                return valorParcelaCorrigida;
  11.            }
  12.            else
  13.            {
  14.                valorParcela = valorParcela - 7.25m;
  15.                return valorParcela;
  16.            }
  17.       }      
  18.     }

Como pode ser visto na Listagem 13, linhas 4 a 17, o m�todo escrito implementa as regras para c�lculo das novas prestaç�es. Sabe-se que o m�todo descobrirSePrestacaoVenceu, sendo invocado na linha 6, j� foi implementado e devidamente testado, ent�o n�o dever� haver problemas para identificar se a prestaç�o venceu. O pr�ximo passo � rodar os testes escritos para o m�todo calcularNovoValorParcela e ver se a l�gica de sua implementaç�o est� correta. A execuç�o dos testes 1 e 2 para o m�todo podem ser vistas nas Figuras 12 e 13.

Figura 12. M�todo de teste 1.

Figura 13. M�todo de teste 2.

Os testes foram executados com sucesso, isto indica que os m�todos escritos passaram em todos os testes que foram pr�-estabelecidos.

Considere ent�o o seguinte cen�rio. Os casos de teste foram devidamente implementados e posteriormente os m�todos da aplicaç�o tamb�m foram implementados, testados e modificados, quando foi necess�rio. O c�digo de teste foi guardado e a aplicaç�o foi entregue ao cliente. Em um determinado momento, um desenvolvedor, ao dar manutenç�o no software desenvolvido, percebeu que a l�gica do m�todo descobrirSePrestacaoVenceu n�o � boa, devido � grande complexidade ciclom�tica (n�mero de caminhos) existente. O desenvolvedor resolve, portanto, substituir todo o c�digo do m�todo por outro bem mais simples, que usa um m�todo de comparaç�o de datas da biblioteca de classes do .Net Framework. Essa mudança ir� simplificar o m�todo descobrirSePrestacaoVenceu.

Como ainda se tem o c�digo de testes, fica mais f�cil se certificar que, ap�s as mudanças, o m�todo ainda estar� passando em todos os testes. A Listagem 14 apresenta o m�todo descobrirSePrestacaoVenceu ap�s ter o c�digo do seu corpo substitu�do por um mais simples e a Figura 14 mostra todos os testes executados ap�s as mudanças no m�todo. As mudanças foram realizadas com sucesso e o m�todo ainda continua fazendo o que sempre fez, agora com um c�digo mais simplificado, e com a garantia de que as mudanças n�o afetaram sua funç�o devido � execuç�o dos testes.

Listagem 14. M�todo descobrirSePrestacaoVenceu ap�s ter o c�digo do seu corpo substitu�do


  1.  public Boolean descobrirSePrestacaoVenceu(DateTime dataVencimento)
  2.  {
  3.      Int32 valor = dataVencimento.CompareTo(DateTime.Today);
  4.      if (valor < 0)
  5.      {
  6.          return true;
  7.      }
  8.      else if(valor == 0)
  9.      {
  10.         return false;
  11.     }
  12.     else
  13.     {
  14.         return false;
  15.     }
  16.     }

Figura 14. Testes executados depois das mudanças em descobrirSePrestacaoVenceu.

Conclus�o

Neste artigo foram apresentadas diversas formas de se implementar c�digo de teste unit�rios. As diferentes formas apresentadas atuam em diferentes contextos, cada um com sua import�ncia. Este artigo visa ser uma refer�ncia para a aplicaç�o de testes unit�rios utilizando NUnit em diferentes cen�rios que podem ser encontrados em diferentes empresas de desenvolvimento.

Se a tecnologia a ser utilizada para testes unit�rios � o NUnit framework, ent�o aqui est�o os conceitos e pr�ticas fundamentais para a definiç�o de c�digo de teste, independentemente dos testes serem implementados antes ou depois do m�todo a ser testado, al�m de tamb�m ser poss�vel testar m�todos que sofreram manutenç�es.

Site para download do NUnit
MARTIN, Robert C, 2009. C�digo Limpo: Habilidades Pr�ticas do Agile Software, 1ed. Rio de Janeiro: Alta Books, 2009.

NUnit: Testes Unit�rios - Revista Engenharia de Software Magazine 43

Este artigo aborda o tema teste unitário com o objetivo de mostrar como o desenvolvedor pode usá-lo para testar o código-fonte de suas aplicações. Neste sentido, o artigo provê conhecimento ao desenvolvedor sobre como implementar casos de teste unitá

NUnit, um framework livre para testes

Utilizando o NUnit no Visual Studio 2008

Criando e executando casos de teste com NUnit

Conclus�o

Artigos relacionados