Testes Unit�rios no Visual Studio

Por mais que a realizaç�o de testes unit�rios se constitua numa atividade de fundamental import�ncia dentro do desenvolvimento de sistemas, n�o � um fato raro que esse tipo de pr�tica acabe negligenciado em muitos projetos de software. In�meros podem ser os motivos que conduzam a problemas deste g�nero, sendo que as causas mais comuns costumam girar em torno de aspectos como tempo escasso, equipes reduzidas e sobrecarregadas em suas tarefas rotineiras, a falta de h�bito em se proceder com testes mais abrangentes, dentre outros fatores.

A principal meta por tr�s do teste de um software � garantir que o produto gerado atenda �quilo que foi especificado para o projeto em quest�o. Em termos pr�ticos, isto implica verificar se a aplicaç�o funciona de maneira correta dentro de uma s�rie de par�metros definidos previamente: pessoas envolvidas com essas tarefas conduzem uma s�rie de atividades validando funcionalidades, tentando, a partir de tais aç�es, encontrar falhas que produzam dados inconsistentes ou, at� mesmo, defeitos que comprometam a operaç�o do sistema. Sem a realizaç�o de procedimentos deste g�nero, tais problemas poderiam passar despercebidos, com consequ�ncias imprevis�veis �s operaç�es rotineiras de uma organizaç�o.

Existem diferentes maneiras de se testar uma aplicaç�o, com cada uma destas levando em conta aspectos como quais profissionais executar�o o processo de validaç�o ou ainda, a extens�o do que ser� verificado. Tomando por base estes crit�rios, os diferentes tipos de testes de software podem ser classificados em:

Teste de unidade (tamb�m conhecido como teste unit�rio): � uma modalidade que se concentra na verificaç�o das menores unidades em um projeto. O teste � realizado em uma unidade l�gica, utilizando dados suficientes apenas para verificar a l�gica da estrutura em quest�o. Unidades em uma linguagem de programaç�o orientada a objetos podem ser identificadas como um m�todo, uma classe ou ainda um objeto;
Teste de integraç�o: procura apontar erros verificando os relacionamentos (interfaces) entre as diferentes partes (m�dulos) que comp�em uma aplicaç�o. Testes de integraç�o costumam auxiliar na construç�o da estrutura de um programa, considerando para isto os requisitos definidos dentro do projeto correspondente;
Teste de sistema: conduzido de maneira a simular a operaç�o de uma aplicaç�o por usu�rios finais, baseando-se num ambiente similar ao do sistema j� em produç�o e na manipulaç�o de dados e informaç�es pr�ximas �quilo que ser� processado no dia a dia;
Teste de aceitaç�o: normalmente um grupo de usu�rios finais do sistema participa desse tipo de teste, visando simular operaç�es cotidianas que determinem se a aplicaç�o est� em conformidade com o que se espera;
Teste de regress�o: realizado quando do lançamento de novas vers�es de um software, checando se as mudanças introduzidas na aplicaç�o n�o produziram efeitos colaterais na execuç�o de funcionalidades pr�-existentes.

Este artigo discutir� a import�ncia dos testes unit�rios no desenvolvimento de software dentro da plataforma .NET. Para isto ser� constru�da uma aplicaç�o de exemplo que usar� os recursos Visual Studio 2012 voltados � execuç�o de testes de unidade automatizados.

Desenvolvimento baseado em Testes Unit�rios: uma vis�o geral

Os testes unit�rios s�o comumente empregados na checagem de m�todos, classes e transiç�es de estados dentro de sistemas orientados a objetos. O trecho de c�digo que ser� testado � conhecido como �System Under Test� - SUT; � comum tamb�m o uso do termo CUT (�Class Under Test� ou �Code Under Test�).

S�o caracter�sticas comumente atribu�das aos testes unit�rios:

S�o automatizados e repet�veis;
Podem ser implementados facilmente;
Uma vez escritos, os testes devem ser mantidos para reuso futuro;
Qualquer profissional envolvido com o desenvolvimento de uma aplicaç�o deve ser capaz de execut�-los;
Facilmente acion�veis, geralmente isso acontece a partir de um bot�o ou item de menu dentro de uma IDE;
Rapidez na execuç�o.

As principais plataformas de desenvolvimento atuais contam com diversos frameworks e funcionalidades que viabilizam a implementaç�o e, consequentemente, a execuç�o automatizada de construç�es deste tipo. No caso espec�fico do .NET Framework, isto pode ser feito atrav�s do uso de frameworks como MS Test (parte integrante da pr�pria plataforma .NET) e NUnit (http://nunit.org/).

Testes unit�rios representam inclusive a base para a forma de desenvolvimento que tem ganho bastante espaço, sobretudo com a crescente popularidade de metodologias �geis como Scrum: trata-se do �Desenvolvimento Guiado por Testes� ou TDD.

TDD (sigla do ingl�s �Test Driven Development�) � um processo para desenvolvimento de software que enfatiza, atrav�s de uma s�rie de princ�pios propostos por metodologias �geis, a construç�o de soluç�es em um modo no qual as mesmas poder�o ser facilmente integradas a uma ferramenta de automaç�o de testes unit�rios.

A escolha do TDD como uma pr�tica de desenvolvimento implica, obrigatoriamente, na codificaç�o dos testes unit�rios antes mesmo da escrita das partes da aplicaç�o que ser�o submetidas aos mesmos. Por mais que um teste possa ser formulado ap�s a codificaç�o de uma funcionalidade, isto n�o � adotado em projetos em conformidade com os princ�pios de TDD: se tal teste fosse elaborado ap�s o desenvolvimento do recurso a ser verificado, o mesmo poderia ser concebido de uma maneira �viciada�, considerando apenas a possibilidade de execuç�o com sucesso da funç�o considerada.

A implementaç�o de um projeto baseado em t�cnicas de TDD � feita seguindo um ciclo conhecido como Red-Green-Refactor, com cada um destes termos correspondendo a uma fase na construç�o dos testes:

Red: o teste � escrito logo no in�cio do desenvolvimento, com a funcionalidade-alvo sequer implementada (normalmente, apenas um �esqueleto� existir�, procurando se aproximar da estrutura esperada para a funç�o em quest�o). O objetivo principal � que esse teste realmente falhe (da� o nome �Red�, um sinal �vermelho� para um problema), cumprindo a meta de evitar uma verificaç�o �viciada�, que sempre resultaria em sucesso na sua execuç�o;
Green: nesta fase � efetuada a codificaç�o da forma mais simples poss�vel, atendendo �quilo que se espera para uma funcionalidade, al�m de garantir que os testes associados ser�o executados com sucesso (sinal �verde� indicando que n�o existem problemas);
Refactor: com os testes tendo passado na etapa anterior, � poss�vel refatorar o item sob an�lise, eliminando prov�veis duplicaç�es e melhorando a estrutura do c�digo. Se este n�o for o caso, o comum � que se passe para os pr�ximos testes unit�rios.

In�meros s�o os benef�cios decorrentes das pr�ticas de TDD:

Um c�digo mais claro, uma vez que os testes unit�rios geralmente efetuam checagens em porç�es menos extensas do mesmo;
Quando bem estruturado, um teste acaba servindo como documentaç�o do c�digo, visto que, a partir da leitura do mesmo, � poss�vel ter uma noç�o do funcionamento de uma classe, m�todo e/ou objeto;
Um r�pido feedback com alertas para problemas encontrados. Isto � poss�vel por conta de diversos testes serem repetidos a cada novo ciclo de desenvolvimento/manutenç�o em uma aplicaç�o;
Testes unit�rios asseguram uma cobertura adequada de diferentes trechos de c�digo, algo que poderia n�o se conseguir somente atrav�s de testes de sistema ou de aceitaç�o (com prov�veis �bugs� aparecendo apenas quando a aplicaç�o estivesse em produç�o);
Maior economia de tempo e de recursos financeiros na manutenç�o de uma aplicaç�o, haja visto que diversas falhas acabam sendo apontadas (e solucionadas) ainda durante a etapa de desenvolvimento.

Diante do exposto, conclui-se que as t�cnicas de TDD, ao favorecer um c�digo mais simples e de f�cil manutenç�o, acabam contribuindo para uma melhor assimilaç�o de boas pr�ticas de desenvolvimento/arquitetura de software:

Desenvolver guiado por testes permite separar a l�gica de neg�cios ou de acesso a dados das camadas gr�ficas de uma aplicaç�o. A este tipo de princ�pio se d� o nome de Separaç�o de Responsabilidades (do ingl�s �Separation of Concerns�), onde o mesmo fornece, atrav�s de uma s�rie de recomendaç�es, diretrizes que conduzam � obtenç�o de aplicaç�es formadas por componentes mais coesos;
Quanto � noç�o de coes�o, este conceito deve ser compreendido como a medida com a qual uma estrutura de software (classe ou componente) atende o objetivo inicial para o qual foi concebida. Uma alta coes�o indica que o item considerado n�o acumula responsabilidades al�m daquelas para as quais foi especificado, uma caracter�stica perseguida por todos os projetos de software que procuram ser bem estruturados. Projetar testes unit�rios de uma maneira simples � tamb�m uma aç�o contribuinte para a obtenç�o de classes mais coesas;
Acoplamento � outro conceito empregado para determinar o grau de relacionamento entre diferentes partes da aplicaç�o. Um alto acoplamento resulta em um n�vel de alta depend�ncia entre os diversos componentes envolvidos, fato este que pode levar a dificuldades na manutenç�o futura das funcionalidades. O ideal � que exista um baixo n�vel de acoplamento entre as estruturas de um determinado elemento. Mais uma vez, testes unit�rios bem estruturados podem auxiliar em classes com baixo acoplamento, diminuindo as depend�ncias entre diferentes componentes da soluç�o base.

Utilizando Testes Unit�rios no Visual Studio 2012

A soluç�o apresentada neste artigo foi criada no .NET framework 4.5, atrav�s do Visual Studio 2012 Professional. Basicamente, ser� implementada uma biblioteca para o c�lculo de tributos federais como PIS, COFINS, ISS e IRPJ; estes est�o geralmente associados a operaç�o fiscais que envolvam a prestaç�o de seguros.

O primeiro passo para a implementaç�o do exemplo baseado em testes unit�rios consiste na criaç�o de uma Solution chamada �TesteNF�, conforme a Figura 1.

Figura 1. Criando a Solution TesteNF.

A soluç�o TesteNF ser� formada pelos seguintes projetos:

TesteNF.Utils: conter� a classe est�tica TributacaoHelper, que disponibiliza operaç�es para o c�lculo dos impostos;
TesteNF.Utils.UnitTesting: aplicaç�o onde estar�o os diversos testes unit�rios respons�veis por verificar as funcionalidades da classe TributacaoHelper.

Uma vez gerado o arquivo correspondente � Solution TesteNF, deve-se prosseguir com a criaç�o de um projeto do tipo Class Library com o nome �TesteNF.Utils� (Figura 2).

Figura 2. Criando a Class Library TesteNF.Utils.

Neste primeiro momento, ser� implementada no projeto TesteNF.Utils uma vers�o extremamente simples da classe TributacaoHelper, com todos os m�todos para c�lculo de impostos retornando zero como resultado de sua execuç�o. O objetivo � justamente assegurar que a primeira bateria de testes unit�rios falhe, de maneira que apenas num segundo momento sejam codificados os c�lculos necess�rios.

Na Tabela 1 est�o indicados as al�quotas para cada um dos impostos calculados por meio do tipo TributacaoHelper.

Imposto	Al�quota
PIS (Programa de Integraç�o Social)	0,0065
COFINS (Contribuiç�o para o Financiamento da Seguridade Social)	0,03
IRPJ (Imposto sobre Renda de Pessoa Jur�dica)	0,015
CSLL (Contribuiç�o Social sobre Lucro L�quido)	0,02

Tabela 1. Al�quotas de impostos que ser�o utilizadas pelo tipo TributacaoHelper

A Listagem 1 tem a definiç�o inicial para a classe TributacaoHelper. Est�o declarados neste tipo os m�todos est�ticos CalcularPIS, CalcularCOFINS, CalcularIRPJ e CalcularCSLL, com cada uma das operaç�es devolvendo como resultado o imposto a ser pago a partir de um valor de serviço prestado.

Listagem 1. Classe TributacaoHelper.


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace TesteNF.Utils
{
    public static class TributacaoHelper
    {
        public static double CalcularPIS(double valorBase)
        {
            return 0;
        }

        public static double CalcularCOFINS(double valorBase)
        {
            return 0;
        }

        public static double CalcularIRPJ(double valorBase)
        {
            return 0;
        }

        public static double CalcularCSLL(double valorBase)
        {
            return 0;
        }
    }
}

Agora � a vez de criar o projeto de testes chamado �TesteNF.Utils.UnitTesting� (Figura 3). Assim como acontece com outros templates, esse tipo de projeto � nativo do Visual Studio e n�o exige qualquer configuraç�o adicional para sua inclus�o em uma Solution.

Figura 3. Criando o projeto TesteNF.Utils.UnitTesting.

Com o projeto TesteNF.Utils.UnitTesting gerado, � poss�vel observar a exist�ncia de um arquivo chamado UnitTest1.cs, tamb�m criado automaticamente, mas pode remov�-lo, j� que outras classes de testes ser�o criadas seguindo uma nomenclatura pr�pria para este projeto.

OBSERVAÇ�O: o projeto TesteNF.Utils.UnitTesting executa o teste de funcionalidades da classe TributacaoHelper, ent�o ser� necess�rio adicionar ao mesmo uma refer�ncia que aponte para a Class Library TesteNF.Utils.

A primeira classe de testes a ser criada ter� o nome �TributacaoHelperTeste01�. O Visual Studio tamb�m oferece um template (�Basic Unit Test�) para este tipo de construç�o, sendo poss�vel selecion�-lo a partir da opç�o que adiciona novos tipos de arquivos a um projeto (conforme indicado na Figura 4).

Figura 4. Criando uma nova classe de teste unit�rio.

Os diferentes testes a serem executados atrav�s da classe TributacaoHelperTeste01 tomar�o R$ 8.400,00 como valor-base para serviços prestados. Na Tabela 2 est�o listados os valores esperados para cada c�lculo de imposto a ser verificado.

Imposto	Operaç�o a ser Verificada em TributacaoHelper	Valor Esperado
PIS	CalcularPIS	54,6
COFINS	CalcularCOFINS	252
IRPJ	CalcularIRPJ	126
CSLL	CalcularCSLL	84

Tabela 2. Valores esperados para os testes da classe TributacaoHelperTeste01.

Na Listagem 2 est� o c�digo corresponde � classe TributacaoHelperTeste01. Nota-se na definiç�o deste tipo as seguintes caracter�sticas:

A classe TributacaoHelperTeste01 foi marcada com o atributo TestClassAttribute, pois, diferente de uma Console Application ou execut�vel Windows Forms, projetos de testes n�o contam com um m�todo Main para iniciar a sua execuç�o; logo, o Visual Studio ir� buscar sempre classes marcadas com o atributo citado, a fim de acionar os diferentes testes presentes nas mesmas;
Os diferentes m�todos que representam testes (TestarCalculoPIS, TestarCalculoCOFINS, TestarCalculoIR e TestarCalculoCSLL) tamb�m est�o marcados com um atributo, sendo que neste �ltimo caso foi utilizado o elemento TestMethodAttribute. Mais uma vez, ser� por meio deste v�nculo que o mecanismo de execuç�o de testes do Visual Studio identificar� quais m�todos precisar�o ser executados;
As verificaç�es de cada funcionalidade presente na classe TributacaoHelper s�o feitas atrav�s do uso do m�todo AreEqual, o qual pertence ao tipo Assert. Esta operaç�o recebe como par�metros o resultado da execuç�o do m�todo a ser testado, al�m do valor esperado para esta aç�o. Caso tais valores n�o coincidam, o teste falhar� e um alerta ser� gerado dentro do Visual Studio.

OBSERVAÇ�O: As classes TestClassAttribute, TestMethodAttribute e Assert est�o situadas no namespace Microsoft.VisualStudio.TestTools.UnitTesting.

Listagem 2. Classe TributacaoHelperTeste01.


using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using TesteNF.Utils;

namespace TesteNF.Utils.UnitTesting
{
    [TestClass]
    public class TributacaoHelperTeste01
    {
        [TestMethod]
        public void TestarCalculoPIS()
        {
            Assert.AreEqual(TributacaoHelper
                .CalcularPIS(8400.00), 54.60);
        }

        [TestMethod]
        public void TestarCalculoCOFINS()
        {
            Assert.AreEqual(TributacaoHelper
                .CalcularCOFINS(8400.00), 252.00);
        }

        [TestMethod]
        public void TestarCalculoIRPJ()
        {
            Assert.AreEqual(TributacaoHelper
                .CalcularIRPJ(8400.00), 126.00);
        }

        [TestMethod]
        public void TestarCalculoCSLL()
        {
            Assert.AreEqual(TributacaoHelper
                .CalcularCSLL(8400.00), 84.00);
        }
    }
}

Durante a construç�o de testes unit�rios, o uso de uma nomenclatura padronizada representa uma boa pr�tica de desenvolvimento. Nos exemplos apresentados neste artigo o nome de todos os m�todos � iniciado pelo prefixo �Testar�. J� a identificaç�o das classes de testes � formada pelo nome do tipo a ser analisado (no caso TributacaoHelper), seguidos pela palavra �Teste�, al�m de n�meros identificadores (�01�, �02�).

Al�m de AreEqual, a classe est�tica Assert (namespace Microsoft.VisualStudio.TestTools.UnitTesting) tamb�m disponibiliza para validaç�es outros m�todos, constituindo exemplos disto as operaç�es:

AreNotEqual: verifica que os valores fornecidos como par�metros s�o diferentes;
IsFalse: checa se o retorno de uma condiç�o � falso;
IsTrue: verifica se o retorno de uma express�o � verdadeiro;
IsNull: checa se o valor associado a um objeto � nulo;
IsNotNull: verifica se o conte�do de um objeto n�o � nulo.

Uma segunda classe de testes chamada TributacaoHelperTeste02 precisar� ser criada. Na Tabela 3 est�o os valores que servir�o de base para os testes, considerando R$ 7.728,00 como total de prestaç�o de serviços.

Imposto	Operaç�o a ser Verificada em TributacaoHelper	Valor Esperado
PIS	CalcularPIS	50,23
COFINS	CalcularCOFINS	231,84
IRPJ	CalcularIRPJ	115,92
CSLL	CalcularCSLL	77,28

Tabela 3. Valores esperados para os testes da classe TributacaoHelperTeste02.

Na Listagem 3 � apresentado o c�digo que define a classe TributacaoHelperTeste02; este tipo conta com uma estrutura id�ntica � da classe TributacaoHelperTeste01, diferindo apenas pelos valores analisados.

Listagem 3 Classe TributacaoHelperTeste02.


using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using TesteNF.Utils;

namespace TesteNF.Utils.UnitTesting
{
    [TestClass]
    public class TributacaoHelperTeste02
    {
        [TestMethod]
        public void TestarCalculoPIS()
        {
            Assert.AreEqual(TributacaoHelper
                .CalcularPIS(7728.00), 50.23);
        }

        [TestMethod]
        public void TestarCalculoCOFINS()
        {
            Assert.AreEqual(TributacaoHelper
                .CalcularCOFINS(7728.00), 231.84);
        }

        [TestMethod]
        public void TestarCalculoIRPJ()
        {
            Assert.AreEqual(TributacaoHelper
                .CalcularIRPJ(7728.00), 115.92);
        }

        [TestMethod]
        public void TestarCalculoCSLL()
        {
            Assert.AreEqual(TributacaoHelper
                .CalcularCSLL(7728.00), 77.28);
        }
    }
}

Agora processaremos os testes: as diferentes opç�es que permitem acionar a execuç�o encontram-se no menu Test (Figura 5).

Figura 5. Menu Test no Visual Studio 2012.

Acionando a opç�o �All Tests� ser� ativada a janela �Test Explorer� (Figura 6) com o resultado da execuç�o das duas classes de testes unit�rios. Conforme pode ser observado, todos os testes falharam.

Figura 6. Listagem dos testes que falharam.

Selecionando um dos testes que falharam ser�o exibidos detalhes a respeito do mesmo como, por exemplo, em que arquivo/classe est� situado o m�todo que produziu a falha (conforme indicado na Figura 7).

Figura 7. Detalhamento de um teste que falhou.

A Listagem 4 apresenta o c�digo referente � classe TributacaoHelper, j� considerando agora as instruç�es necess�rias para o c�lculo dos diversos impostos previstos por este tipo.

OBSERVAÇ�O: para a aplicaç�o de exemplo foram utilizados valores fixos nas al�quotas de impostos. Numa situaç�o real, o ideal seria que tais al�quotas fossem parametriz�veis, ou seja, definidas em um arquivo de configuraç�o ou, at� mesmo, numa tabela pertencente dentro de uma base de dados.

Listagem 4. Classe TributacaoHelper ap�s a implementaç�o dos c�lculos de impostos.


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace TesteNF.Utils
{
    public static class TributacaoHelper
    {
        public static double CalcularPIS(double valorBase)
        {
            return Math.Round(valorBase * 0.65 / 100, 2);
        }

        public static double CalcularCOFINS(double valorBase)
        {
            return Math.Round(valorBase * 3 / 100, 2);
        }

        public static double CalcularIRPJ(double valorBase)
        {
            return Math.Round(valorBase * 1.5 / 100, 2);
        }

        public static double CalcularCSLL(double valorBase)
        {
            return Math.Round(valorBase * 1 / 100, 2);
        }
    }
}

Uma nova execuç�o dos testes unit�rios resultar� em sucesso desta vez, como pode ser visualizado na Figura 8.

Figura 8: Execuç�o com sucesso de todos os testes.

Observando o c�digo que implementa a classe TributacaoHelper, nota-se que em todos os m�todos repete-se o uso da operaç�o Round, a qual se encontra definida na classe est�tica Math (namespace System). Al�m disso, em todas as situaç�es a al�quota � dividida por 100, obtendo o valor decimal correspondente a uma porcentagem. Este � um bom exemplo no qual t�cnicas de refatoraç�o podem ser empregadas: um m�todo chamado CalcularImposto � implementado agrupando as instruç�es comuns com, o mesmo sendo acionado pelas demais operaç�es de TributacaoHelper (Listagem 5).

Listagem 5: Classe TributacaoHelper refatorada.


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace TesteNF.Utils
{
    public static class TributacaoHelper
    {
        private static double CalcularImposto(
            double valorBase, double aliquota)
        {
            return Math.Round(valorBase * aliquota / 100, 2);
        }

        public static double CalcularPIS(double valorBase)
        {
            return CalcularImposto(valorBase, 0.65);
        }

        public static double CalcularCOFINS(double valorBase)
        {
            return CalcularImposto(valorBase , 3);
        }

        public static double CalcularIRPJ(double valorBase)
        {
            return CalcularImposto(valorBase, 1.5);
        }

        public static double CalcularCSLL(double valorBase)
        {
            return CalcularImposto(valorBase, 1);
        }
    }
}

Reprocessando os testes ap�s essa etapa de refatoraç�o, nota-se que os mesmos ainda s�o v�lidos, o que significa que n�o foram introduzidos erros no c�digo-fonte (Figura 9).

Figura 9. Testes executados com sucesso ap�s refatoraç�o da classe TributacaoHelper.

Com isso, procurou-se demonstrar como testes unit�rios podem ser utilizados a partir do Visual Studio 2012. O desenvolvimento guiado por testes pode resultar n�o apenas na obtenç�o de aplicaç�es com menor sujeiç�o a erros, como tamb�m contribuir para uma melhor estruturaç�o do sistema ao estimular o uso de boas pr�ticas de arquitetura.

Contudo, � altamente recomend�vel n�o depender apenas de testes unit�rios para a validaç�o de uma aplicaç�o. As outras modalidades de testes s�o important�ssimas e devem ser aplicadas ao longo das diferentes fases de um projeto, garantindo um produto est�vel, sem falhas que impeçam sua operaç�o normal no dia a dia.

Testes Unit�rios no Visual Studio 2012

Veja neste artigo como implementar testes unitários no Visual Studio 2012, contribuindo assim para a construção de aplicações menos sujeitas a falhas e com uma melhor estruturação do código-fonte.

Desenvolvimento baseado em Testes Unit�rios: uma vis�o geral

Utilizando Testes Unit�rios no Visual Studio 2012

Artigos relacionados