TDD (Test-Driven Development) em aplica��es .NET

Fique por dentro

Este artigo � �til porque apresentar� para o leitor a metodologia Test-Driven Development (TDD) e como aplic�-la em projetos .NET.

O TDD preza pela realizaç�o de testes no c�digo antes mesmo de implementar as funcionalidades propriamente ditas, reduzindo a quantidade de erros, aumentando a qualidade do c�digo e permitindo ao desenvolvedor conhecer melhor as regras de neg�cio que est�o sendo implementadas.

Veremos tamb�m como utilizar a t�cnica de mock no apoio ao TDD, pr�tica bastante �til em cen�rios onde � necess�rio realizar testes com dados fict�cios, pois facilita a geraç�o de objetos para testes a partir de modelos do dom�nio da aplicaç�o.

Durante o ciclo de vida de um software, os requisitos inicialmente estabelecidos geralmente mudam, novos s�o adicionados e outros removidos.

Claro que isso n�o vem de hoje, mas tornou-se muito mais constante devido �s novas possibilidades de produzirmos softwares para diversas plataformas, por exemplo.

Sempre estamos evoluindo e os estilos tradicionais de desenvolvermos novos produtos enfrentam desafios significativos, como a necessidade constante de facilitar a manutenç�o.

Realizar alteraç�es em uma aplicaç�o desenvolvida e prestes a entrar para o mercado, tradicionalmente, pode causar indisposiç�o junto aos seus clientes de formas dif�ceis de serem previstas.

Como resultado, as organizaç�es hesitam em fazer mudanças que s�o necess�rias para o software, impedindo assim o seu melhor desempenho e consequentemente seu sucesso perante as organizaç�es que dele dependam.

Neste quesito, no que diz respeito � mudança, � que entramos no tema deste artigo, cujo foco � trabalhar em testes com base na metodologia Test-Driven Development (TDD).

O intuito deste artigo � apresentar de forma pr�tica e simples como podemos trabalhar numa aplicaç�o baseando-se em testes para as funcionalidades que desejamos implementar, de forma a reduzir falhas no sistema.

Com TDD podemos aumentar a nossa produtividade, pois iremos reduzir a quantidade de depuraç�es necess�rias para detecç�o de erros, teremos uma melhor visualizaç�o do nosso c�digo, tornando mais simples a leitura dele, dentre outras vantagens que refletem de forma direta na construç�o de um software de qualidade.

Para praticar os conceitos que ser�o apresentados aqui, criaremos uma aplicaç�o simples de carrinho de compras, no qual estaremos vendo a utilizaç�o de um �simulador de banco de dados� conhecido por Moq, que auxilia na geraç�o de dados fict�cios para testes.

Uma pr�via sobre TDD

Nos �ltimos anos, houve uma s�rie de novidades em torno da metodologia de TDD e sua real efic�cia com relaç�o ao desenvolvimento das mais diversas aplicaç�es. Mesmo com a desenvoltura que podemos encontrar nas t�cnicas do TDD, ainda existe muita relut�ncia na sua utilizaç�o, principalmente relacionada aos prazos para desenvolvimento e entrega de projetos.

Ao trabalharmos com desenvolvimento baseado em testes, temos primeiramente a mudança do nosso foco, que neste momento passa a se voltar para tecnologias �geis e pr�ticas baseadas em testes como sendo as operaç�es prim�rias para o desenvolvimento de sistemas complexos e de alto desempenho.

O Test Driven Development � uma metodologia de desenvolvimento avançado com foco na qualidade do software orientado a objetos, amplamente utilizado dentro da comunidade Agile. O que torna o TDD �nico � o seu foco na especificaç�o do projeto, ao inv�s de ser na sua validaç�o.

A abordagem TDD leva a uma melhor arquitetura de software de qualidade, melhorando a qualidade, simplicidade e capacidade de teste, enquanto aumenta a confiança no c�digo e a produtividade da equipe.

Ao implementarmos essa metodologia, os testes utilizados s�o compostos de afirmaç�es verdadeiras e falsas que indicam o comportamento correto com relaç�o ao teste que est� sendo usado no momento.

Nesta abordagem criamos testes automatizados de unidades antes mesmo de escrevermos o c�digo espec�fico. Ao escrevermos inicialmente os testes, estes n�o s� nos ajudam na mediç�o dos testes propriamente ditos, mas tamb�m forçam o desenvolvedor a se concentrar no conceito do design avançado desde o in�cio.

Atrav�s do desenvolvimento de um conjunto de casos de teste funcional inicialmente, os desenvolvedores podemos ter a certeza de que ter�o sempre um software com o m�nimo de falha poss�vel, al�m de que as caracter�sticas rec�m-aplicadas ser�o aplicadas conforme o esperado.

Para o TDD, temos que uma unidade � definida basicamente como sendo uma classe ou um grupo de funç�es relacionadas, muitas vezes chamado de m�dulo. Com a disposiç�o de unidades relativamente pequenas, podemos oferecer benef�cios cr�ticos � nossa aplicaç�o, como � o caso da reduç�o dos esforços no momento da depuraç�o, al�m de que testes pequenos melhoram a legibilidade e compreens�o mais r�pida e eficiente do que � preciso fazer.

O ciclo do TDD: Red-Green-Refactor

O TDD � conduzido por uma filosofia b�sica, conhecida como "Red-Green-Refactor" (Figura 1), que � um microciclo de desenvolvimento iterativo no qual os testes e comportamentos s�o implementados.

Neste processo, o que ocorre primeiramente � que os casos de teste rec�m-escritos testam o c�digo ainda n�o escrito e, devido a isso, falham. Esta � a primeira etapa, definida como Red.

A partir deste momento o desenvolvedor implementa o recurso da maneira mais simples, fazendo com que os testes correspondentes sejam bem-sucedidos, o que representa o segundo passo do ciclo, o Green.

E por fim, antes de começarmos com um novo teste, podemos realizar o processo de refatoraç�o do c�digo de forma a deix�-lo o mais claro e eficiente poss�vel, de forma a proporcionar confiança pela capacidade de executar o teste novamente que foi implementado.

Este � o terceiro item do ciclo, a Refatoraç�o (ou Refactor). Ao adotarmos o ciclo Red-Green-Refactor, temos que o nosso c�digo pode evoluir para um n�vel superior de comunicaç�o simplificada, confiança e produtividade global.

Figura 1.Ciclo RGR (Red-Green-Refactor).

Ao trabalharmos com base no ciclo TDD, somos levados a desenvolver de forma mais r�pida, de forma que, ao termos uma alteraç�o no c�digo conclu�do, este ser� testado automaticamente. Isso mostra que se tivermos um erro, este ser� percebido quase que imediatamente.

O imediatismo e a localidade do feedback s�o muito valiosos. Um microciclo eficaz requer compilaç�o e execuç�o de casos de teste r�pidos. Este requisito � fundamental para sustentar o ritmo de desenvolvimento e reduç�o da impertin�ncia de testes.

Uma t�cnica chave � permitir a execuç�o autom�tica de casos de teste como uma atividade p�s-compilaç�o, que combina construç�o e teste em uma �nica etapa de desenvolvimento. Para que possamos realizar as atividades de forma a seguir os conceitos do TDD, temos que seguir alguns passos simples:

Criar um novo teste;
Executar o teste garantindo que este ir� falhar (sim, falhar);
Escrever c�digo suficiente para que o teste seja aprovado;
Refatorar o c�digo testado;
Nos certificarmos de que ao refatorarmos, o c�digo n�o seja quebrado;
Repetir o processo at� que todos os testes foram escritos e aprovados.

Estes s�o os seis passos que devemos ter em mente ao trabalharmos com base no ciclo do TDD para que possamos ter nossas aplicaç�es dentro do padr�o correto e mais simples poss�vel.

Por que utilizar o TDD em nossas aplicaç�es?

Como qualquer outra metodologia de desenvolvimento, o TDD exige uma mudança de paradigmas com foco no c�digo para uma abordagem baseada em testes. Ao adotarmos uma abordagem de desenvolvimento orientada a testes, � necess�rio um esforço significativo, podendo requerer da organizaç�o de desenvolvimento uma mudança de cultura. Por�m os benef�cios referentes a estas mudanças podem ultrapassar os custos que podem ser acarretados. Esta mudança melhora a qualidade e a confiabilidade do sistema, maximiza a produtividade do desenvolvedor e acelera significativamente o tempo para a disponibilidade do projeto no mercado profissional. Vejamos a seguir alguns dos benef�cios obtidos na adoç�o do TDD.

Mais qualidade no projeto

Com o TDD, cada componente � obrigado a ser constru�do de forma constante com capacidade a n�vel elevado de qualidade, de forma mais consistente com base nos testes, onde temos o desenvolvimento em pequenos incrementos, que exigem testes para serem aprovados.

Uma vez que o componente desenvolvido individualmente muda para a integraç�o, este n�vel elevado de qualidade nos componentes leva a uma r�pida integraç�o e testes mais eficazes.

O esforço para construir uma ampla base de testes automatizados de forma incremental ao longo do ciclo de desenvolvimento, produz uma base muito mais completa e valiosa de testes do que um esforço em testes apressados, e muitas vezes �espremidos� no final do projeto. Durante todo o ciclo de desenvolvimento o foco maior em testes ajuda a manter um foco maior sobre a qualidade em geral.

Este investimento cont�nuo em qualidade rende benef�cios significativos ao n�vel geral do sistema.

C�digo mais simples

Durante a implementaç�o de um recurso, o desenvolvedor orientado a testes escreve o c�digo mais simples para fazer os testes passarem. O TDD ajuda aos desenvolvedores a evitarem o excesso de soluç�es engenhosas devido ao seu microciclo de desenvolvimento. Ela tamb�m ajuda a quebrar o problema em unidades modulares e produzir uma soluç�o que possa ser testada, bem como implementada. Esta abordagem para o desenvolvimento tem o efeito de simplificaç�o no c�digo do projeto e alcança os benef�cios associados a ela, incluindo melhoria na legibilidade e compreensibilidade. Quanto mais complexo o problema, mais importante � garantir que cada unidade est� codificada de uma forma simples tanto quanto poss�vel.

Reduç�o do tempo para disponibilizar o produto

O ciclo do TDD � mais curto que o ciclo de desenvolvimento tradicional. Concentrando-se em desenvolver apenas o que � necess�rio para a aprovaç�o nos testes, usando esse feedback imediato para reduzir os erros de regress�o, o ciclo de desenvolvimento pode ser rapidamente reduzido ao seu n�cleo essencial.

Normalmente, os atrasos de integraç�o para os sistemas aumentar�o com o tempo de desenvolvimento do software e estender�o o cronograma das entregas. Ao aplicarmos o TDD, temos a maioria dos problemas de componentes resolvidos muito mais cedo no processo, diminuindo assim o tempo de integraç�o e a rapidez para o produto completo estar no mercado.

Mais flexibilidade no projeto

A realidade atual de conduç�o de neg�cios no ramo de softwares inclui a concorr�ncia acirrada, prazos reduzidos e mais apertadas janelas de mercado. As oportunidades n�o esperam por momentos convenientes para emergir.

O TDD aumenta a capacidade de uma organizaç�o com base no desenvolvimento de software para responder rapidamente �s mudanças de requisitos ou mesmo �s atualizaç�es de produto imprevistas, facilitando os ciclos de desenvolvimento e de integraç�o mais curtos e apoiando o r�pido aperfeiçoamento de novas exig�ncias.

Uma cultura s�lida de TDD com uma rica base de teste � a melhor preparaç�o para que se possa aproveitar rapidamente as oportunidades e vencer a concorr�ncia no mercado.

Para que possamos nos familiarizar com alguns dos recursos oferecidos pelo TDD, estaremos desenvolvendo aplicaç�es simples no decorrer do artigo, onde o nosso primeiro exemplo ser� referente a operaç�es matem�ticas e, em seguida, teremos uma aplicaç�o mais realista, na qual faremos uma simulaç�o de operaç�es de inserç�o numa base de dados. Para os nossos projetos, estaremos trabalhando com o Visual Studio 2015.

Para darmos in�cio � nossa aplicaç�o inicial, criaremos um novo projeto do tipo ASP.NET Web Application e a ele daremos o nome de DevmediaTDD, como mostra a Figura 2. Em seguida, na tela que ser� apresentada, selecionaremos um template vazio e marcaremos a opç�o �Add Unit Tests�, o qual deixaremos com o mesmo nome do projeto, como apresentado pela Figura 3.

Figura 2. Criando um novo projeto ASP.NET.

Figura 3. Selecionando o Template.

Agora que temos nosso projeto criado, realizaremos algumas configuraç�es para que possamos trabalhar com o NUnit, que � um framework de testes de unidade para todas as linguagens .NET. Este framework � escrito em C# e foi completamente redesenhado para tirar proveito dos muitos recursos do .NET, como os atributos personalizados. No per�odo em que esse artigo foi escrito, o NUnit 3.0 est� atualmente em desenvolvimento, apresentando uma nova infraestrutura e novos recursos. Trabalharemos ent�o com a vers�o beta dispon�vel.

Para adicionarmos o NUnit ao nosso projeto, devemos clicar com o bot�o direito sobre o projeto DevmediaTDD.Tests e selecionar a opç�o Manage NuGet Packages. Em seguida, buscaremos por NUnit, como mostra a Figura 4, e ao encontrarmos o pacote desejado, o instalaremos. Ao finalizarmos a instalaç�o, percebam que a refer�ncia foi adicionada ao projeto, como mostra a Figura 5.

Figura 4. Instalando o NUnit.

Figura 5. Visualizando o NUnit nas refer�ncias do projeto.

Perceba na Figura 4, que com a nova vers�o do Visual Studio, o gerenciador NuGet apresenta de melhor forma as informaç�es sobre os pacotes que estamos precisando. Al�m disso, temos a vers�o do pacote do NUnit que estamos instalando, que � uma vers�o Beta. Para finalizarmos com as atualizaç�es do ambiente, selecionaremos no menu �Tools� a opç�o �Extensions and Updates� para adicionarmos o NUnit Test Adapter, como mostram as Figuras 6 e 7. Com esta extens�o podemos rodar nossos testes dentro do Visual Studio.

Figura 6. Selecionando a opç�o Extensions and Updates.

Figura 7. Habilitando o NUnit TestAdapter.

Para habilitarmos o NUnit Test Adapter, precisamos fazer o download dele para a aplicaç�o. No nosso caso, as opç�es que s�o apresentadas s�o a de Disable ou Uninstall, devido ao fato de j� termos ele instalado.

Com o nosso ambiente configurado, iremos agora utilizar a classe UnitTest1, que foi criada automaticamente. Nesta classe, faremos inicialmente uma modificaç�o, que � a de usarmos o NUnit Framework, adicionando o �using NUnit.Framework�. Esta classe por padr�o, traz configuraç�es do MSUnit, outro framework de testes, mas que n�o utilizaremos neste artigo. Vejamos ent�o de acordo com a Listagem 1 como ficar� a nossa classe inicialmente.

Listagem 1. Classe UnitTest1.cs.


     using System;
     using NUnit.Framework;
     namespace DevmediaTDD.Tests
     {
     [TestFixture]
     public class UnitTest1
     {
     [Test]
     public void TestMethod1()
     {
     }
     }
     }

Dentre os recursos oferecidos pelo NUnit, temos o atributo TestFixture, que � utilizado para indicar que uma classe cont�m m�todos de teste. Quando adicionamos este atributo para uma classe no projeto, a aplicaç�o Test Runner ir� buscar pelos m�todos de testes. Al�m dele, tamb�m temos o atributo [Test] que � usado para indicar que um m�todo dentro da aplicaç�o deve ser executado pelo Test Runner. Alteremos ent�o a nossa classe de testes para realizar algumas operaç�es matem�ticas, como apresentado de acordo com a Listagem 2.

Listagem 2. Teste de operaç�es matem�ticas.


            namespace DevmediaTDD.Tests
            {
            [TestFixture]
            public class UnitTest1
            {
            [Test]
            public void soma()
            {
            Assert.AreEqual(12, 10 + 2);
            }
            [Test]
            public void subtracao()
            {
            Assert.AreEqual(5, 8 - 3);
            }
            [Test]
            public void multiplicacao()
            {
            Assert.AreEqual(15, 5*2);
            }
            }
            }

Antes de executarmos nossa aplicaç�o, perceba que um novo item foi adicionado, que foi o �Assert�, onde temos que o NUnit nos fornece um rico conjunto de afirmaç�es como m�todos est�ticos da classe Assert. Alguns dos m�todos presentes nesta classe s�o o AreEqual, AreNotEqual, Contains, Greater, IsFalse, dentre outros.

Com nossa classe criada, temos agora que testar e ver os resultados. Para que possamos executar os testes, devemos selecionar na barra de tarefas o item Test e em seguida, Run e por �ltimo, colocar todos os testes para serem executados, como podemos ver na Figura 8.

Figura 8. Executando todos os testes.

Ao realizarmos os testes, devemos obter os resultados como esperado, de acordo com a Figura 9, onde temos que duas das operaç�es foram bem-sucedidas, enquanto que uma apresentou erro, no caso, o m�todo de multiplicaç�o.

Figura 9. Visualizaç�o do resultado no Test explorer.

Como podemos observar nessa figura, temos os m�todos que foram aprovados e o que foi reprovado. Podemos clicar em cima de cada um e ver na guia que aparece abaixo as informaç�es referentes ao processo. No nosso caso, selecionamos a opç�o que apresenta o erro, e nela vemos que a mensagem que � apresentada � que o valor esperado seria 15, mas o que retornou foi 10. No StackTrace(), � apresentado um link no qual, se clicamos, somos levados diretamente � linha na qual se encontra o erro.

Criando um projeto de Carrinho de compras

Agora que tivemos essa pequena introduç�o ao uso do NUnit, iremos criar um novo exemplo que ser� referente � criaç�o de um carrinho de compras bem simples, no qual teremos algumas das operaç�es b�sicas.

Começaremos ent�o criando um novo projeto Web Application, o qual chamaremos de CarrinhoCompras, em seguida selecionaremos a opç�o de template �Empty� e marcaremos a opç�o de criar classe de testes, como fizemos no exemplo anterior.

Ao iniciarmos o projeto, primeiramente apagaremos a classe que foi criada automaticamente e em seguida adicionaremos uma nova classe, a qual chamaremos de ItensCarrinho. Esta classe ser� respons�vel por testarmos os itens que ser�o inclu�dos no carrinho, dentre as informaç�es, temos a quantidade de itens e a descriç�o, al�m do preço referente � quantidade de produtos, como podemos ver na Listagem 3.

Listagem 3. Criaç�o da classe de testes ItensCarrinho.


            using System;
            using NUnit.Framework;
            namespace CarrinhoCompras.Tests
            {
            [TestFixture]
            public class ItensCarrinho
            {
            private int _quantidade;
            private string _descricao;
            private ItensCarrinho _itemCarrinho;
            private decimal _precoUnitario;
            private decimal _precoItem;
            [SetUp]
            public void SetUp()
            {
            _quantidade = 2;
            _precoUnitario = 3.00m;
            _precoItem = _quantidade* _precoUnitario;
            _descricao = "Teste de descriç�o do produto";
            _itemCarrinho = new ItensCarrinho(_quantidade, _descricao, _precoUnitario);
            }
            [Test]
            public void QtdItens()
            {
            Assert.AreEqual(_itemCarrinho.Quantidade, _quantidade);
            }
            [Test]
            public void DescricaoItem()
            {
            Assert.AreEqual(_itemCarrinho.Descricao, _descricao);
            }
            [Test]
            public void PrecoUnitario()
            {
            Assert.AreEqual(_itemCarrinho.PrecoUnitario, _precoUnitario);
            }
            [Test]
            public void ValorProdutoQtd()
            {
            var valorAtual = _itemCarrinho.PrecoQtdProduto();
            Assert.AreEqual(valorAtual, _precoItem);
            }
            }
            }

Podemos perceber nessa listagem um novo atributo utilizado, que � o [SetUp], o qual � aplicado dentro do TestFixture para fornecer um conjunto comum de funç�es que ser�o executadas antes que cada m�todo de teste seja executado. Algo que devemos observar neste ponto � que para cada TextFixture, deve haver apenas um [SetUp], pois caso haja mais que isso, ele compilar� normalmente, mas os testes n�o ser�o executados.

Outro ponto a ser notado aqui � com relaç�o � criaç�o de uma inst�ncia da classe ItensCarrinho, a qual foi criada dentro do projeto CarrinhoCompra, definida de acordo com a Listagem 4.

Listagem 4. Criaç�o da classe ItensCarrinho.


                    namespace CarrinhoCompras
                    {
                    public class ItensCarrinho
                    {
                    public int Quantidade { get; set; }
                    public string Descricao { get; set; }
                    public decimal PrecoUnitario { get; set; }
                    public ItensCarrinho(int qtd, string desc, decimal precoUnitario)
                    {
                    Quantidade = qtd;
                    Descricao = desc;
                    PrecoUnitario = precoUnitario;
                    }
                    // M�todo respons�vel por realizar o c�lculo do valor do produto pela quantidade de itens.
                    public decimal PrecoQtdProduto()
                    {
                    return Quantidade* PrecoUnitario;
                    }
                    }
                    }

Para darmos continuidade, criaremos uma nova classe de testes, clicando com o bot�o direito no projeto CarrinhoCompras.Tests e selecionando a opç�o de adicionar um novo item. Na tela que ser� apresentada, selecionaremos a opç�o Test Class e daremos o nome de CarrinhoTests, como mostra a Figura 10.

Figura 10. Adicionando uma nova classe de testes.

Nesta nova classe de testes, faremos algumas validaç�es, como � o caso de adiç�o de um mesmo item de compra no carrinho, valor total de compra, dentre outras situaç�es que podemos precisar. O c�digo da nossa classe de testes CarrinhoTests � apresentada na Listagem 5.

Listagem 5. Criaç�o da classe de testes CarrinhoTests.cs.


            using System;
            using System.Text;
            using System.Collections.Generic;
            using NUnit.Framework;
            namespace CarrinhoCompras.Tests
            {
            [TestFixture]
            public class CarrinhoTests
            {
            private Carrinho _carrinho;
            private ItensCarrinho _itens;
            private ItensCarrinho _itens2;
            [SetUp]
            public void SetUp()
            {
            _carrinho = new Carrinho();
            _itens = new ItensCarrinho(3, "Testes", 8.00m);
            _itens2 = new ItensCarrinho(4, "Testes 2", 6.00m);
            }
            [Test]
            public void CarrinhoComZeroItems()
            {
            Assert.AreEqual(_carrinho.itens.Count, 0);
            }
            [Test]
            public void AdicionaItemCarrinho()
            {
            _carrinho.AdicionaItem(_itens);
            Assert.That(_carrinho.itens, Has.Member(_itens));
            }
            [Test]
            public void ContemItemDuplicado()
            {
            _carrinho.AdicionaItem(_itens);
            _carrinho.AdicionaItem(_itens);
            Assert.That(_carrinho.itens.Count, Is.EqualTo(1));
            }
            [Test]
            public void RemoveItemCarrinho()
            {
            _carrinho.AdicionaItem(_itens);
            _carrinho.RemoveItem(_itens);
            Assert.That(_carrinho.itens.Count, Is.EqualTo(0));
            }
            [Test]
            public void ValorTotalCarrinho()
            {
            _carrinho.AdicionaItem(_itens);
            _carrinho.AdicionaItem(_itens2);
            var _somaProdutos = _carrinho.valorTotalCompras();
            Assert.That(_somaProdutos, Is.EqualTo(48.00m));
            }
            }
            }

Para que possamos testar o carrinho de compras, precisamos da classe Carrinho, que deve ser criada no projeto CarrinhoCompras. Esta classe � representada pelo c�digo apresentado pela Listagem 6. Percebam neste caso que temos a apresentaç�o de um novo item do grupo dos Asserts, que � o Assert.That, que � bem semelhante ao Assert.AreEqual.

Listagem 6. Criaç�o da classe Carrinho.cs.


            using System.Collections.Generic;
            namespace CarrinhoCompras
            {
            public class Carrinho
            {
            public List<ItensCarrinho> itens { get; set; }
            public Carrinho()
            {
            itens = new List<ItensCarrinho>();
            }
            public void AdicionaItem(ItensCarrinho item)
            {
            // Verifica se a lista j� cont�m um item igual adicionado
            if (itens.Contains(item)) { return; }
            itens.Add(item);
            }
            public void RemoveItem(ItensCarrinho item)
            {
            itens.Remove(item);
            }
            public decimal valorTotalCompras()
            {
            decimal ValorTotal = 0m;
            foreach(var item in itens)
            {
            ValorTotal += item.PrecoQtdProduto();
            }
            return ValorTotal;
            }
            }
            }

Ap�s termos a noç�o de como podemos trabalhar com testes em classes simples, veremos agora na nossa aplicaç�o uma simulaç�o de inserç�o de dados numa base de dados. Para isso, trabalharemos com o framework Moq e realizaremos algumas modificaç�es nas nossas classes criadas at� o momento.

De forma bem simples, temos que os objetos mock s�o uma �tima maneira de simularmos um objeto no qual precisamos trabalhar. Esses objetos podem ser utilizados para que possamos simular diversas situaç�es, como erros de rede, ou mesmo uma falha espec�fica no banco de dados.

Outro grande benef�cio sobre os frameworks de simulaç�o � que os dados externos que podemos estar utilizando n�o ser�o afetados por nenhuma alteraç�o realizada. Podemos simplesmente simular uma chamada ao banco de dados e n�o afetar o nosso banco de dados real.

Ao trabalharmos com testes unit�rios, precisamos escrever testes que cobrem uma �rea espec�fica de c�digo, neste momento, o c�digo ou classe em teste pode interagir com outras classes ou sistemas externos, mas n�s s� precisamos isolar a classe que estamos trabalhando.

Quando trabalhamos com TDD, ele se torna de grande ajuda, pois evita que precisemos utilizar dados reais para testes. O Moq � um framework open source e adota uma API que tenta ser ao mesmo tempo simples de aprender e f�cil de utilizar. A API tamb�m segue o estilo Arrange-Act-Assert e se baseia fortemente nos recursos do .NET, como express�es lambda e m�todos de extens�o.

Quando nos referimos ao estilo Arrange-Act-Assert, temos que ter em mente o que cada um desses processos significa. Começamos por Arrange (organizar), que � o primeiro passo a ser visto numa aplicaç�o de teste da unidade.

Neste ponto, temos a organizaç�o do teste, onde trataremos das configuraç�es necess�rias para que ele possa ser executado, significando que para realizarmos o teste, precisaremos inicialmente criar um objeto da classe que ter� o foco de nossas atenç�es.

O outro ponto � o Act (agir), que � o passo intermedi�rio de uma aplicaç�o e � onde executaremos o nosso teste. Por �ltimo, temos o Assert (afirmaç�o), neste ponto iremos verificar o resultado retornado juntamente com o resultado esperado e ver se s�o compat�veis ou n�o.

Para começarmos a trabalhar com o Moq Framework, iremos adicion�-lo ao nosso projeto utilizando novamente o NuGet, onde buscaremos por Moq e realizaremos a instalaç�o, como mostra a Figura 11.

Figura 11. Instalaç�o do Moq framework.

Com o Moq instalado, precisaremos agora realizar algumas modificaç�es referentes �s nossas classes, onde precisaremos criar as interfaces necess�rias para a utilizaç�o desse framework em nosso projeto. Dito isso, a nossa interface para inserç�o de dados no carrinho de compras ser� definida conforme a Listagem 7.

Listagem 7. Criaç�o da interface ICarrinhoDatabase.


            namespace CarrinhoCompras
            {
            public interface ICarrinhoDatabase
            {
            long InsereCarrinho(Carrinho _carrinho);
            }
            }

Na nossa classe em quest�o, temos apenas um m�todo chamado InsereCarrinho, no qual temos a classe Carrinho sendo utilizada para que possamos recuperar suas informaç�es. Em seguida, criaremos nossa classe de testes que ir� utilizar a nossa interface juntamente com o Moq Framework, como podemos ver na Listagem 8.

Listagem 8. Criaç�o da classe CarrinhoReposit�rioTests.cs.


            using NUnit.Framework;
            using Moq;
            namespace CarrinhoCompras.Tests
            {
            [TestFixture]
            public class CarrinhoRepositorio
            {
            private MockRepository _mockRepositorio;
            private Mock<ICarrinhoDatabase> _carrinhoBancoDados;
            private Carrinho carrinho;
            [SetUp]
            public void SetUp()
            {
            _mockRepositorio = new MockRepository(MockBehavior.Strict);
            _carrinhoBancoDados = _mockRepositorio.Create<ICarrinhoDatabase>();
            carrinho = new Carrinho();
            }
            [Test]
            public void SalvarCarrinho()
            {
            _carrinhoBancoDados.Setup(c => c.InsereCarrinho(carrinho)).Returns(1001);
            var repositorio = new carrinhoDBRepositorio(_carrinhoBancoDados.Object);
            var resultado = repositorio.salvaCarrinho(carrinho);
            Assert.AreEqual(resultado, 1001);
            }
            [Test]
            public void ErroAoSalvarCarrinhoCompras()
            {
            _carrinhoBancoDados.Setup(c => c.InsereCarrinho(carrinho)).Throws<ApplicationException>();
            var repositorio = new carrinhoDBRepositorio(_carrinhoBancoDados.Object);
            var resultado = repositorio.salvaCarrinho(carrinho);
            Assert.AreEqual(resultado, 0);
            }
            }
            public class carrinhoDBRepositorio
            {
            private ICarrinhoDatabase _carrinhoDB;
            public carrinhoDBRepositorio(ICarrinhoDatabase carrinhoBancoDados)
            {
            _carrinhoDB = carrinhoBancoDados;
            }
            public long salvaCarrinho(Carrinho carrinhoCompras)
            {
            long retorno;
            try
            {
            retorno = _carrinhoDB.InsereCarrinho(carrinhoCompras);
            }
            catch (Exception ex)
            {
            retorno = 0;
            }
            return retorno;
            }
            }
            }

Nessa classe temos dois m�todos de testes, que s�o o de ErroAoSalvarCarrinhoCompras que ir� levantar uma exceç�o quando o valor retornado for zero, e o SalvarCarrinho, referente ao salvamento dos dados do carrinho.

Caso todas as informaç�es estejam corretas, o resultado esperado � que seja apresentado o c�digo de inserç�o que estamos representando pelo valor 1001.

Perceba tamb�m que nesta classe definimos a classe p�blica chamada carrinhoDBRepositorio, na qual temos definido o m�todo p�blico SalvaCarrinho, que verifica dentro de um Try...Catch se o retorno das operaç�es foi nulo ou se retornou o valor correto.

Um ponto importante a ser destacado nessa classe � a utilizaç�o do Mock<ICarrinhoDatabase>, que � utilizado para inicializar uma inst�ncia do Mock por default. Al�m dele, temos o MockRepository, que � uma classe reposit�rio utilit�ria utilizada para construir m�ltiplas simulaç�es para uma verificaç�o.

Esta classe reposit�rio ajuda no cen�rio de v�rias simulaç�es serem criadas durante um teste, fornecendo uma criaç�o simplificada dessas v�rias simulaç�es com um MockBehavior padr�o.

O MockBehavior, por sua vez, � um Enum que apresenta as opç�es para personalizarmos o comportamento da nossa simulaç�o. No nosso caso utilizamos o Strict, que faz com que a simulaç�o lance uma exceç�o sempre que as chamadas n�o tiverem uma configuraç�o correspondente.

As outras opç�es do Behavior que podem ser utilizadas s�o a Loose e a Default. A Loose, nunca vai lançar exceç�es, retornando valores padr�o quando necess�rio, de igual forma ao Default.

Com toda essa etapa tendo sido vista, iremos trabalhar com um novo objeto no nosso dom�nio, que ser� o Cliente que poder� ser tanto um cliente comum quanto um cliente especial. Primeiramente, criaremos a nossa classe de testes para o projeto, a qual ser� chamada de ClienteComprasTests. Para essa classe teremos o c�digo que ser� parecido com o apresentado na Listagem 9.

Listagem 9. Criando a classe de testes ClienteComprasTests.


                using NUnit.Framework;
                using Moq;
                using System.Linq;
                namespace ClienteComprasTestes.Tests
                {
                [TestFixture]
                public class ClienteTests
                {
                public IClienteRepositorio mockClienteRepositorio { get; private set; }
                [Test]
                public void ClienteCarrinho()
                {
                // Criando alguns dados de teste
                IList<Cliente> clientes = new List<Cliente>
                {
                new Cliente { ClienteId = 1, Nome = "Edson Dionisio",
                Email = "edson.dionisio@gmail.com", Telefone = "8197402803",
                Endereco = "Rua dos testes Devmedia",
                Profissao = "Desenvolvedor web", DataCadastro = now() },
                new Cliente { ClienteId = 2, Nome = "Marilia Kessia",
                Email = "mkessia@gmail.com", Telefone = "8197499820",
                Endereco = "Rua dos testes Devmedia",
                Profissao = "Professora de lingua inglesa", DataCadastro = now() },
                new Cliente { ClienteId = 3, Nome = "Mait� Dionisio",
                Email = "maite.dionisio@gmail.com", Telefone = "8197499820",
                Endereco = "Rua dos testes Devmedia", Profissao = "Analista de softwares", DataCadastro = now() },
                new Cliente { ClienteId = 4, Nome = "Mait� Dionisio",
                Email = "maite.dionisio@gmail.com", Telefone = "8197499820",
                Endereco = "Rua dos testes Devmedia", Profissao = "Analista de softwares", DataCadastro = now() },
                new Cliente { ClienteId = 5, Nome = "Tatsu Yamashiro",
                Email = "tatsu.yamashiro@gmail.com", Telefone = "8197490000",
                Endereco = "Rua dos testes Devmedia", Profissao = "Designer de aplicaç�es", DataCadastro = now() }
                };
                // Simulaç�o com Moq para o reposit�rio
                Mock<IClienteRepositorio> mockClienteRepositorio = new Mock<IClienteRepositorio>();
                // Retornando todos os clientes
                mockClienteRepositorio.Setup(clienteRepo => clienteRepo.BuscarTodos()).Returns(clientes);
                // Retornando os clientes com base no c�digo
                mockClienteRepositorio.Setup(clienteRepo => clienteRepo.BuscaPorId(It.IsAny<int>())).Returns((int i)
                => clientes.Where(c => c.ClienteId == i).Single());
                // Retornando os clientes por nome
                mockClienteRepositorio.Setup(cliente => cliente.FindByNome(It.IsAny<string>())).Returns((string s)
                => clientes.Where(c => c.Nome == s).Single());
                // Verificaç�o para a adiç�o do cliente
                mockClienteRepositorio.Setup(cliente => cliente.Salvar(It.IsAny<Cliente>())).Returns(
                (Cliente cliente) =>
                {
                DataCadastro Data = DateTime.Now;
                if (cliente.ClienteId.Equals(default(int)))
                {
                cliente.ClienteId = clientes.Count() + 1;
                clientes.Add(cliente);
                }
                else
                {
                var original = clientes.Where(c => c.ClienteId == cliente.ClienteId).Single();
                if (original == null)
                {
                return false;
                }
                original.ClienteId = cliente.ClienteId;
                original.Nome = cliente.Nome;
                original.Email = cliente.Email;
                original.Telefone = cliente.Telefone;
                original.Endereco = cliente.Endereco;
                original.Profissao = cliente.Profissao;
                original.DataCadastro = cliente.DataCadastro;
                }
                return true;
                });
                this.mockClienteRepositorio = mockClienteRepositorio.Object;
                }

Como podemos perceber nessa listagem, temos inicialmente a criaç�o de um teste para listar os clientes que est�o na �base de dados�.

Foram passados alguns dados fict�cios para que pud�ssemos realizar este teste e criamos dois meios de pesquisa, os quais s�o tanto por ID do cliente quanto pelo nome do mesmo. Nesse exemplo percebemos a introduç�o de um novo item pertencente ao Moq, que � o m�todo IsAny<T>, o qual � respons�vel por testar se algum dos valores fornecidos equivale aos dados pesquisados.

Outro item apresentado que faz parte do Moq Framework � o Setup, que tem por finalidade especificar uma configuraç�o do tipo simulada (mock) atrav�s de uma chamada para um m�todo de valor de retorno. Continuando com a nossa classe de testes, adicionaremos novos testes que ser�o referentes ao retorno dos clientes, cujo c�digo pode ser visto na Listagem 10.

Listagem 10. M�todos de teste para retorno de informaç�es do cliente.


            [Test]
            public void RetornarClientePorNome()
            {
            // Encontrar cliente por nome
            Cliente clienteRetorno = this.mockClienteRepositorio.FindByNome("Edson Dionisio");
            Assert.IsNotNull(clienteRetorno);
            Assert.AreEqual(4, clienteRetorno.ClienteId);
            }
            [Test]
            public void TodosClientesRetornar()
            {
            // Buscar por todos os clientes
            IList<Cliente> clienteRetorno = this.mockClienteRepositorio.BuscarTodos();
            Assert.IsNotNull(clienteRetorno);
            Assert.AreEqual(5, clienteRetorno.Count);
            }

Temos ent�o dois m�todos respons�veis pela apresentaç�o das informaç�es do cliente, onde temos que no primeiro m�todo retornamos as informaç�es com base no nome do cliente, j� no segundo retornamos todos os clientes. A seguir, teremos os dois �ltimos m�todos da classe de testes, que s�o os m�todos de inserç�o e ediç�o de clientes, como podemos ver na Listagem 11.

Listagem 11. Criaç�o dos m�todos de testes para Inserç�o e ediç�o de cliente.


                [Test]
                public void ClientePodeSerInserido()
                {
                // Inserindo um novo cliente
                Cliente insereCliente = new Cliente
                { Nome = "Edson testes 2", Email = "edson.testes@testes.com", Telefone = "97402803", Endereco = "Rua dos testes",
                Profissao = "Testes", DataCadastro = now() };
                // Salvando um novo cliente
                this.mockClienteRepositorio.Salvar(insereCliente);
                }
                [Test]
                public void ClientePodeSerAlterado()
                {
                // Buscando o cliente pelo Id
                Cliente clienteRetorno = this.mockClienteRepositorio.BuscaPorId(1);
                // Realizando a ediç�o do nome do cliente para teste
                clienteRetorno.Nome = "Edson Dionisio 2";
                // Salvando as alteraç�es realizadas para o cliente
                this.mockClienteRepositorio.Salvar(clienteRetorno);
                // Aqui verificamos se todas as informaç�es foram trazidas certas
                Assert.AreEqual("Edson Dionisio 2", this.mockClienteRepositorio.BuscaPorId(1).Nome);
                }

Com a nossa classe de testes definida, teremos agora que criar os nossos arquivos referentes � interface para o reposit�rio, chamada de IClienteRepositorio, e a classe Cliente.cs. Vejamos ent�o como a interface dever� ser, de acordo com a Listagem 12.

Listagem 12. Criaç�o da interface IClienteRepositorio.


            using System.Collections.Generic;
            namespace CarrinhoCompras
            {
            public interface IClienteRepositorio
            {
            IList<Cliente> BuscarTodos();
            Cliente FindByNome(string clienteNome);
            Cliente BuscaPorId(int clienteId);
            bool Salvar(Cliente cliente);
            }
            }

Definimos o m�todo Salvar() como sendo bool, pois ele retornar� apenas se foi inserido ou n�o, apresentando true ou false. Por �ltimo, temos a criaç�o da classe Cliente.cs, como podemos ver na Listagem 13.

Listagem 13. Criaç�o da classe Cliente.cs.


            namespace CarrinhoCompras
            {
            public class Cliente
            {
            public int ClienteId { get; set; }
            public string Email { get; set; }
            public string Endereco { get; set; }
            public string Telefone { get; set; }
            public string Nome { get; set; }
            public string Profissao { get; set; }
            public string DataCadastro { get; set; }
            }
            }

Com isso finalizamos o nosso exemplo, onde criamos as nossas classes de testes antes de interagirmos com nossas classes b�sicas e regras de neg�cio propriamente ditas. Claro que al�m das vantagens que podemos ter ao utilizarmos TDD, tamb�m temos desvantagens, onde a que podemos considerar mais cr�tica � aprender a desenvolver orientado a testes.

Neste momento, temos nossas atenç�es voltadas para a criaç�o de nossos pequenos blocos de testes que constituem basicamente a ideia chave de como teremos aquela regra aplicada no nosso c�digo real. Mas uma vez que entendemos o processo e nos acostumamos a trabalhar dessa forma, o nosso trabalho torna-se muito mais produtivo e bem avaliado pelos empregadores.

Com a utilizaç�o de testes automatizados, temos a confiança de desenvolvermos softwares de forma a termos uma aplicaç�o com menos bugs e que possui uma maior confiabilidade e credibilidade no mercado. Al�m disso, temos tamb�m uma maior agilidade com relaç�o a modificarmos um c�digo que n�o conhecemos sem a apresentaç�o de novos erros.

Como aqui temos a necessidade de testarmos pequenos blocos de c�digo, a fim de faz�-los funcionar, temos nosso foco centrado apenas nesta ideia, onde a cada novo teste adicionado, n�o haver� uma falha sendo criada em conjunto.

� medida que nossos softwares v�o crescendo, temos a necessidade de aplicarmos mais e mais recursos, que se n�o forem bem testados, poder�o nos causar alguns transtornos ao produzir bugs que possam afetar o desempenho de uma empresa.

Eis uma das maiores raz�es de utilizarmos o Test-Driven Development, produzir softwares de qualidade e com baixo �ndice de falhas.

Links

Site oficial do NUnit

Site oficial do Moq Framework

Confira tamb�m

Cursos de .NET

Cursos

Minha primeira aplicaç�o C#

Curso

Guias .NET

Guia

Introdu��o ao Desenvolvimento Guiado por Testes

Veja neste artigo como aplicar o TDD (Test-Driven Development) no desenvolvimento de aplicações .NET guiadas por testes com o Visual Studio, além de como utilizar Mock para facilitar a simulação de dados para testes.