A Import�ncia dos Testes Automatizados

Controle �gil, r�pido e confi�vel de qualidade

Controlar a qualidade de sistemas de software � um grande desafio devido � alta complexidade dos produtos e �s in�meras dificuldades relacionadas ao processo de desenvolvimento, que envolve quest�es humanas, t�cnicas, burocr�ticas, de neg�cio e pol�ticas. Idealmente, os sistemas de software devem n�o s� fazer corretamente o que o cliente precisa, mas tamb�m faz�-lo de forma segura, eficiente e escal�vel e serem flex�veis, de f�cil manutenç�o e evoluç�o.

Salvo honrosas exceç�es, na ind�stria de software brasileira, estas caracter�sticas s�o muitas vezes asseguradas atrav�s de testes manuais do sistema ap�s o t�rmino de m�dulos espec�ficos ou at� mesmo do sistema inteiro. Como veremos mais adiante neste artigo, esta abordagem manual e ad hoc leva � ocorr�ncia de muitos problemas e deve ser evitada. Este artigo se inspira na filosofia dos M�todos �geis de Desenvolvimento de Software e em pr�ticas recomendadas pela Programaç�o eXtrema (XP), em especial nos Testes Automatizados, que � uma t�cnica voltada principalmente para a melhoria da qualidade dos sistemas de software. Este artigo apresenta tamb�m alguns exemplos de testes automatizados baseados em excelentes ferramentas dispon�veis como software livre.

Cen�rio comum de desenvolvimento

O modo convencional de desenvolvimento de uma funcionalidade � estudar o problema, pensar em uma soluç�o e, em seguida, implement�-la. Ap�s esses tr�s passos, o desenvolvedor faz testes manuais para verificar se est� tudo funcionando como o esperado. � normal que defeitos sejam detectados ao longo do processo de desenvolvimento, ent�o os desenvolvedores precisam encontrar o defeito, corrigi-lo e refazer o conjunto de testes manuais.

Al�m disso, para verificar se algum erro deixou de ser identificado durante a fase de desenvolvimento, antes de colocar o sistema em produç�o � muito comum submeter o software a um processo de avaliaç�o de qualidade. Esse controle de qualidade geralmente � realizado com o aux�lio de testes manuais executados por desenvolvedores, usu�rios ou mesmo por equipes especializadas em testes.

Este cen�rio � comum principalmente em empresas que utilizam metodologias r�gidas que possuem fases bem definidas, geralmente derivadas do modelo de cascata. Este tipo de metodologia pode levar � apariç�o de diversos problemas recorrentes na ind�stria de software, tais como atrasos nas entregas, criaç�o de produtos com grande quantidade de erros e dificuldade de manutenç�o e evoluç�o. Isto se deve em parte �s dificuldades da realizaç�o de testes manuais.

A execuç�o manual de um caso de teste � r�pida e efetiva, mas a execuç�o e repetiç�o de um vasto conjunto de testes manualmente � uma tarefa muito dispendiosa e cansativa. � normal e compreensivo que os testadores n�o verifiquem novamente todos os casos a cada mudança significativa do c�digo; � deste cen�rio que surgem os erros de software, trazendo preju�zo para as equipes de desenvolvimento que perdem muito tempo para identificar e corrigir os defeitos e tamb�m preju�zo para o cliente que, entre outros problemas, sofre com constantes atrasos nos prazos combinados e com a entrega de software de qualidade duvidosa.

Mas o aspecto mais cr�tico deste cen�rio � o efeito �bola de neve�. Como � necess�rio muito esforço para executar todo o conjunto de testes manuais, dificilmente a cada correç�o de um defeito, a bateria de testes ser� executada novamente como seria desej�vel. Muitas vezes, isso leva a erros de regress�o (erros em m�dulos do sistema que estavam funcionando corretamente e deixam de funcionar). A tend�ncia � este ciclo se repetir at� que a manutenç�o do sistema se torne uma tarefa t�o custosa que passa a valer a pena reconstru�-lo completamente.

Uma nova abordagem

Muitos m�todos �geis como Lean, Scrum e XP (vide refer�ncias) recomendam que todas as pessoas de um projeto (programadores, gerentes, equipes de homologaç�o e at� mesmo os clientes) trabalhem controlando a qualidade do produto todos os dias e a todo momento, pois acreditam que prevenir defeitos � mais f�cil e barato que identific�-los e corrigi-los. A Programaç�o eXtrema, em particular, recomenda explicitamente testes automatizados para ajudar a garantir a qualidade dos sistemas de software. Vale ressaltar ainda que os m�todos �geis n�o se op�em a quaisquer revis�es adicionais que sejam feitas para aumentar a qualidade.

Testes automatizados s�o programas ou scripts simples que exercitam funcionalidades do sistema sendo testado e fazem verificaç�es autom�ticas nos efeitos colaterais obtidos. A grande vantagem desta abordagem � que todos os casos de teste podem ser facilmente e rapidamente repetidos a qualquer momento e com pouco esforço.

A reproduç�o dos testes permite simular identicamente e in�meras vezes situaç�es espec�ficas, garantindo que passos importantes n�o ser�o ignorados por falha humana e facilitando a identificaç�o de um poss�vel comportamento n�o desejado.

Al�m disso, como os casos para verificaç�o s�o descritos atrav�s de um c�digo interpretado por um computador, � poss�vel criar situaç�es de testes bem mais elaboradas e complexas do que as realizadas manualmente, possibilitando qualquer combinaç�o de comandos e operaç�es. A magnitude dos testes pode tamb�m facilmente ser alterada. Por exemplo, � trivial simular centenas de usu�rios acessando um sistema ou inserir milhares de registros em uma base de dados, o que n�o � fact�vel com testes manuais.

Todas estas caracter�sticas ajudam a minimizar os problemas encontrados nos testes manuais, diminuindo a quantidade de erros e aumentando a qualidade do software. Como � relativamente f�cil executar todos os testes a qualquer momento, mudanças no sistema podem ser feitas com segurança, o que aumenta a vida �til do produto.

Na grande maioria das vezes, os testes automatizados s�o escritos programaticamente, por isso � necess�rio conhecimento de programaç�o. Nas seç�es seguintes veremos alguns exemplos de c�digo de testes automatizados que utilizam algumas ferramentas e arcabouços livres bem populares. No entanto, existem alguns tipos de testes que possuem ferramentas gr�ficas que escondem os detalhes de implementaç�o permitindo que outros profissionais tamb�m consigam escrever seus pr�prios testes, por exemplo JMeter para testes de estresse e desempenho e Selenium-IDE para criaç�o de testes de interface gr�fica para aplicaç�es Web (ver seç�o Links) .

Exemplo de Teste Automatizado de Unidade

Se o leitor quer começar a colocar em pr�tica testes automatizados, o primeiro tipo de teste que se deve fazer s�o os de unidade. Uma unidade pode ser entendida como o menor trecho de c�digo de um sistema que pode ser testado, podendo ser uma funç�o ou m�dulo em programas procedimentais ou m�todos ou classes em programas orientados a objetos. O teste de uma unidade � o tipo mais importante de teste para a grande maioria das situaç�es, j� que � ele que deve testar se um algoritmo faz o que deveria ser feito e garantir que o c�digo encapsulado por uma unidade deve produzir o efeito colateral esperado. Outra vantagem importante � que o teste de unidade � focalizado em um trecho espec�fico do c�digo, desta forma os defeitos encontrados s�o facilmente localizados, diminuindo o tempo gasto com depuraç�o.

Uma pr�tica comum no passado (at� a d�cada de 90) era criar uma funç�o de teste em cada m�dulo ou classe do sistema que continha algumas simulaç�es de uso da unidade. O problema desta pr�tica est� na falta de organizaç�o, j� que o c�digo adicional era misturado ao pr�prio sistema afetando a legibilidade do c�digo. Por isso, surgiram os arcabouços (frameworks) que auxiliam e padronizam a escrita de testes automatizados, facilitando o isolamento do c�digo de teste do c�digo da aplicaç�o. Estes arcabouços de testes de unidade s�o conhecidos como parte da fam�lia de arcabouços xUnit. Por exemplo, existe o arcabouço pioneiro SUnit para SmallTalk criado por Kent Beck, que foi seguido por implementaç�es para outras linguagens, tais como JUnit e TestNG para Java, JSUnit para Javascript, CppTest para C++, csUnit para .NET, entre outras (ver seç�o Links).

Para ilustrar, vamos ver um exemplo de teste automatizado para aplicaç�es Java com o aux�lio da vers�o 4 do popular JUnit. Os testes s�o organizados em casos de teste definidos atrav�s de anotaç�es Java @Test antes da definiç�o de cada m�todo de teste. O arcabouço tamb�m possui uma gama de m�todos auxiliares para comparar os efeitos colaterais esperados com os obtidos, tais como assertEquals que compara a igualdade do conte�do de objetos, assertSame que compara se duas refer�ncias se referem ao mesmo objeto, assertNull que verifica se uma dada refer�ncia � nula, entre outros (ver Listagem 1).

Listagem 1. Exemplo de teste automatizado com o JUnit 4


        public class ExemploJUnitTest {

        @Test // Este m�todo � um caso de teste

        public void testaAdicaoDeDiasEmUmaData() throws Exception {

        SimpleDateFormat formatador = new SimpleDateFormat("dd/MM/yyyy");

        Date dataDeReferencia = formatador.parse("05/06/2008");

        Date dataDaqui5Dias = formatador.parse("10/06/2008");

        Date dataObtida = DateUtil.adicionaDiasEmUmaData(dataDeReferencia, 5);

        assertEquals(dataDaqui5Dias, dataObtida);

        }

        }

Uma caracter�stica comum a muitos arcabouços de testes que facilita ainda mais o desenvolvimento dos testes automatizados � o conjunto de ferramentas auxiliares que as integram com ferramentas e ambientes de programaç�o (IDE), facilitando a execuç�o da bateria de testes e a leitura dos resultados obtidos. Na Figura 1 vemos o relat�rio gerado com os resultados dos testes executados dentro da IDE Eclipse (ver seç�o Links). O relat�rio cont�m uma barra que fica verde quando todos os testes passam com sucesso, ou vermelha quando pelo menos um caso de teste falha. Para facilitar a localizaç�o de erros, � impressa a pilha de execuç�o apenas dos testes que falharam.

Figura 1. Relat�rio dos testes do plug-in do JUnit para a IDE Eclipse

O arcabouço � bem simples, assim como os c�digos dos testes devem ser. Com esta noç�o b�sica da ferramenta j� � poss�vel ao leitor criar seus pr�prios testes automatizados para seus projetos. No entanto, � recomendado um estudo um pouco mais profundo para que seus testes tenham mais qualidade. Duas caracter�sticas fundamentais para garantir a qualidade dos testes s�o: simplicidade e legibilidade.

O c�digo do teste, assim como o c�digo do sistema, pode conter erros; por isso, � imprescind�vel que o c�digo do teste seja o mais simples poss�vel. Evite testes longos, c�digo repleto de condiç�es (ifs), testes respons�veis por muitas verificaç�es e tamb�m nomes obscuros.

� tamb�m importante que a legibilidade dos testes seja boa para facilitar a sua manutenç�o e para se obter pistas expl�citas de qual funcionalidade est� quebrada quando um teste falhar. Al�m disso, testes claros e leg�veis podem ser utilizados como documentaç�o do sistema ou como base para gerar a documentaç�o atrav�s dos relat�rios dos resultados. A Listagem 2 cont�m um exemplo de um teste para um algoritmo que recebe um inteiro representando uma quantidade de segundos (enviado ao construtor da classe Horario) e devolve uma String representando um display digital (m�todo formatoDeRelogioDigital).

Listagem 2. Bateria de testes para a classe Horario


        @Test

        public void displayDeSegundosDeveExibirDe00Ate59() {

        assertEquals("00:00:00", new Horario(0).formatoDeRelogioDigital());

        assertEquals("00:00:01", new Horario(1).formatoDeRelogioDigital());

        assertEquals("00:00:05", new Horario(5).formatoDeRelogioDigital());

        assertEquals("00:00:59", new Horario(59).formatoDeRelogioDigital());

        assertTrue(new Horario(60).formatoDeRelogioDigital().endsWith(":00"));

        assertTrue(new Horario(61).formatoDeRelogioDigital().endsWith(":01"));

        }



        @Test

        public void displayDeMinutosDeveExibirDe00Ate59() {

        assertEquals("00:01:00", new Horario(60).formatoDeRelogioDigital());

        assertEquals("00:01:01", new Horario(61).formatoDeRelogioDigital());

        assertEquals("00:02:00", new Horario(120).formatoDeRelogioDigital());

        assertEquals("00:02:59", new Horario(179).formatoDeRelogioDigital());

        assertEquals("00:03:00", new Horario(180).formatoDeRelogioDigital());

        assertEquals("00:59:59", new Horario(59 * 60 + 59).formatoDeRelogioDigital());

        assertTrue(new Horario(60*60).formatoDeRelogioDigital().endsWith("00:00"));

        assertTrue(new Horario(60*60 + 1).formatoDeRelogioDigital().endsWith("00:01"));

        assertTrue(new Horario(60*60 + 120).formatoDeRelogioDigital().endsWith("02:00"));

        }



        @Test

        public void displayDeHorasDeveExibirDe00Ate23() {

        assertEquals("00:59:59", new Horario(3599).formatoDeRelogioDigital());

        assertEquals("01:00:00", new Horario(3600).formatoDeRelogioDigital());

        assertEquals("01:00:01", new Horario(3601).formatoDeRelogioDigital());

        assertEquals("01:10:01", new Horario(4201).formatoDeRelogioDigital());

        assertEquals("02:00:01", new Horario(7201).formatoDeRelogioDigital());

        assertEquals("02:26:01", new Horario(7201 + 26 * 60).formatoDeRelogioDigital());

        assertEquals("23:59:59", new Horario(24 * 3600 - 1).formatoDeRelogioDigital());

        assertEquals("00:00:00", new Horario(24 * 3600).formatoDeRelogioDigital());

        }



        @Test

        public void displayDeveReiniciarSeAQuantidadeDeSegundosForMaiorQueDeUmDiaCompleto() {

        assertEquals("00:00:01", new Horario(24 * 3600 + 1).formatoDeRelogioDigital());

        assertEquals("00:01:00", new Horario(24 * 3600 + 60).formatoDeRelogioDigital());

        }



        @Test

        public void displayQuantidadeDeSegundosNegativaDeveExibirDisplayZerado() {

        assertEquals("00:00:00", new Horario(-1).formatoDeRelogioDigital());

        assertEquals("00:00:00", new Horario(-100).formatoDeRelogioDigital());

        }

Exemplo de Teste de Inteface Web

Outro tipo de teste importante � o de aceitaç�o, que visa verificar se o que foi implementado atende corretamente ao que o cliente esperava, ou seja, validar o sistema do ponto de vista do cliente. Normalmente, estes testes s�o realizados atrav�s da interface de usu�rio que pode ser, por exemplo, um console textual, uma interface de uma aplicaç�o local ou uma interface Web. A escrita deste tipo de teste exige mais do que chamadas de m�todos e procedimentos. Para se testar uma funcionalidade � necess�ria a simulaç�o das aç�es de um usu�rio interagindo com o programa, isto �, um clique do mouse, uma tecla pressionada, uma opç�o selecionada, entre outras aç�es. Por isso � fundamental a utilizaç�o de arcabouços que consigam abstrair as aç�es de usu�rio encapsulando o funcionamento interno das interfaces para facilitar a escrita e manutenç�o dos testes de aceitaç�o.

Este � um tipo de teste bem abrangente, pois envolve todas as camadas do sistema, dependendo da modelagem correta da base de dados, do funcionamento correto dos m�dulos internos do sistema, da integraç�o entre eles e da interaç�o do usu�rio com a interface. Portanto, escrever bons testes de aceitaç�o que verifiquem adequadamente todos estes componentes � uma tarefa n�o-trivial que exige um bom conhecimento e experi�ncia.

A Listagem 3 ilustra um exemplo de teste automatizado de uma interface Web com o aux�lio das ferramentas Selenium, Selenium Remote Control (Selenium RC) e JUnit. O Selenium, diferentemente de outras ferramentas, permite executar os testes diretamente nos navegadores mais populares (Firefox, Internet Explorer, Opera, Safari), o que torna poss�vel testar facilmente a compatibilidade de um projeto Web �s diferentes plataformas. J� o Selenium RC permite que o c�digo dos testes seja escrito em v�rias linguagens de alto n�vel, por exemplo, Java, Ruby, Python ou C#. O JUnit recebe as informaç�es obtidas do navegador e compara com os valores esperados.

Listagem 3. Exemplo de teste com Selenium-RC e JUnit


        @Test

        public void testaPaginaDoProjetoQualipso() throws Exception {

        String url = "http://www.qualipso.org";

        String servidor = "localhost";

        String porta = 4444;

        String navegador = "*firefox";

        Selenium selenium = new DefaultSelenium(servidor, porta, navegador, url);



        selenium.start(); // Abre o navegador



        // Entra no site

        selenium.open("/");

        // Verifica se um texto apareceu

        assertTrue(selenium.isTextPresent("It is all about trust"));

        // Clica em um link

        selenium.click("link=Work Areas");

        // Espera carregar a nova p�gina

        selenium.waitForPageToLoad("30000");

        // Verifica se apareceu um outro texto

        assertTrue(selenium.isTextPresent("TRUSTWORTHY RESULTS"));



        selenium.stop(); // Fecha o navegador

        }

A classe DefaultSelenium possui m�todos prontos que abstraem o funcionamento interno de eventos dos navegadores, tais como click ou select que simulam um clique do mouse em um objeto e a seleç�o de uma opç�o em caixas de seleç�o, respectivamente. Todos os m�todos que fazem uma interaç�o com um objeto em particular exigem um argumento que permite a identificaç�o do objeto. Este argumento pode ser express�es DOM (Document Object Model - linguagem para permitir que programas acessem e modifiquem dinamicamente objetos de um documento HTML) ou XPath (XML Path Language - linguagem para identificar trechos espec�ficos de um arquivo XML) (ver seç�o Links), ou simplesmente um identificador definido no c�digo HTML. Desta forma, o c�digo do teste passa a ser um exemplo de uso do sistema.

Consideraç�es Finais

Desenvolvimento de software � uma tarefa complexa que exige conhecimento t�cnico, organizaç�o, atenç�o, criatividade e tamb�m muita comunicaç�o. � previs�vel que, em alguns momentos do desenvolvimento, em algumas das milhares de linhas de c�digo, alguns destes requisitos falhe, mas � imprevis�vel o momento no qual eles ir�o falhar. Por isso, � imprescind�vel que exista uma maneira f�cil e �gil de executar todos os testes em qualquer instante, e isso s� � vi�vel com o aux�lio de testes automatizados.

A automaç�o dos testes d� segurança � equipe para fazer alteraç�es no c�digo, seja por manutenç�o, refatoraç�o ou at� mesmo para adiç�o de novas funcionalidades. Al�m disso, representar casos de teste atrav�s de programas possibilita a criaç�o de testes mais elaborados e complexos, que poder�o ser repetidos in�meras vezes.

Conseq�entemente, a quantidade de tempo gasto com a verificaç�o do sistema aumenta, enquanto diminui o tempo gasto com a identificaç�o e correç�o de erros, j� que eles tendem a ser encontrados mais cedo. � medida que o tempo passa, o sistema vai crescendo e os programadores v�o esquecendo certos detalhes de implementaç�o, por isso quanto mais tarde um erro for encontrado, mais trabalhosa ser� a depuraç�o para a sua localizaç�o.

Com essas noç�es b�sicas de testes automatizados, o leitor pode se aprofundar no assunto pesquisando a automaç�o de outros tipos de testes, estudando padr�es de escrita de bons testes automatizados e o Desenvolvimento Dirigido por Testes, que � uma t�cnica na qual os testes guiam a implementaç�o do sistema. Outro t�pico importante � a execuç�o autom�tica dos testes que pode ser feita com o aux�lio de ferramentas que ficam constantemente verificando se um c�digo foi alterado ou com ferramentas que executam a bateria de testes periodicamente.

Refer�ncias

AgilCoop: Possui artigos, palestras, podcasts e v�deos relacionados a M�todos �geis
QualiPSo
Beck, K.; Andres C. Extreme Programming Explained: Embrace Change. Segunda ediç�o. Ed. Addison-Wesley, 2004.
Poppendieck M.; Poppendieck T. Lean Software Development: An Agile Toolkit. Ed. Addison-Wesley, 2003
Schwaber, K.; Beedle, M. Agile Software Development with SCRUM. Ed. Prentice Hall, 2001.
Beck, K. Test-Driven Development: By Example. Ed. Addison-Wesley Professional, 2002
Delamaro, M.; Maldonado, J.; Jino, M. Introduç�o ao Teste de Software. Ed. Campus, 2007

Esse artigo faz parte da revista Engenharia de Software 3 ediç�o especial. Clique aqui para ler todos os artigos desta ediç�o

Artigo Engenharia de Software 3 - A Import�ncia dos Testes Automatizados

Controlar a qualidade de sistemas de software é um grande desafio devido à alta complexidade dos produtos e às inúmeras dificuldades relacionadas ao processo de desenvolvimento.