O FlexUnit 4 é a mais nova versão (não tem a oficial, só a RC, por enquanto) e apresenta uma série de vantagens sobre o seu antecessor, o FlexUnit 0.9, como os metadados de teste ([Test], [After] e [Before], para citar as mais populares), Theories, DataPoints e Assumptions que são úteis para testar grandes quantidades (talvez até infinita) de dados e ver como a aplicação se comporta e a possibilidade de executar os testes com diferentes Runners.

Este tutorial tem como objetivo mostrar o básico de testes unitários no Flex, sem se aprofundar muito nos recursos avançados do framework de testes.  Eu pretendo ir postando mais tutoriais à medida que eu for me aprofundando na tecnologia.

O setup

Para usar o FlexUnit4, você precisa baixa-lo aqui. Após isso, crie um projeto no Flex Builder e adicione todas as libs que vieram no pacote no seu diretório libs:

Verifique se todas as libs estão lá

Como o bom e velho TDD manda, vamos primeiro escrever a classe de teste de exemplo antes de escrever nosso código de produção.

A classe de teste

Uma classe de testes é uma classe comum que usa a classe Assert para fazer asserções. No exemplo que irei mostrar, usarei dois tipos básicos de asserção, mas se você observar, o FlexUnit possui vários tipos diferentes de asserções:

package tests
{
	import org.flexunit.Assert;
	import org.flexunit.runner.manipulation.filters.IncludeAllFilter;

	import production.BasicClass;

	public class BasicTests
	{
		public function BasicTests(){}
		private var basicClass:BasicClass;

		[Before]
		public function before():void
		{
			basicClass = new BasicClass();
		}

		[Test]
		public function Verifica_Se_As_Duas_Strings_Sao_Iguais():void
		{
			var str:String = "MinhaString";
			Assert.assertTrue(basicClass.areStringsEqual(str,"MinhaString"));
		}

		[Test]
		public function Verifica_Se_A_Soma_Retorna_Resultado_Correto():void
		{
			var soma:int = 10;
			Assert.assertEquals(soma,basicClass.somar(2,8));
		}

		[After]
		public function after():void
		{
			//codigo de after
		}

	}
}

A suíte de teste

A suíte de testes inclui nosso caso de teste descrito acima e será útil para o Flex executar nossos testes. Sendo assim, nossa suíte de testes ficaria mais ou menos desse jeito:

package tests
{
	[Suite]
	[RunWith("org.flexunit.runners.Suite")]
	public class MyTestSuite
	{
		public var baseTest:BasicTests;
		public function MyTestSuite(){}

	}
}

UITestRunner e o FlexUnitCore

O UITestRunner é um componente do FlexUnit que mostra os testes numa interface gráfica. Ele ficará na nossa aplicação e mostrará os resultados dos testes.

O FlexUnitCore será o responsável por carregar as suítes de teste e por passar os dados de saída de testes para o UITestRunner. No nosso caso, nossa aplicação principal ficaria assim:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" creationComplete="run()" layout="absolute" xmlns:flexUnitUIRunner="http://www.adobe.com/2009/flexUnitUIRunner">
    <mx:Script>
    <![CDATA[
       import tests.MyTestSuite;
       import org.flexunit.listeners.UIListener;
       import org.flexunit.runner.FlexUnitCore;

       public var core:FlexUnitCore;
       public function run():void
       {
           core = new FlexUnitCore();
           core.addListener(new UIListener(uiRunner));
           core.run(MyTestSuite);
      }
    ]]>
   </mx:Script>
   <flexUnitUIRunner:TestRunnerBase id="uiRunner"  width="100%" height="100%"/>
</mx:Application>

O código de produção

Ufa! Depois de escrever a classe de teste, a suíte de teste e o runner, podemos nos focar em fazer nosso código de produção . Dêem uma olhada em como ficaria o dito:

package production
{
	public class BasicClass
	{
		public function BasicClass(){}

		public function areStringsEqual(string1:String,string2:String):Boolean
		{
			return (string1==string2);
		}

		public function somar(valor1:int,valor2:int):int
		{
			return valor1+valor2;
		}

	}
}

E Voilà!

Depois de tudo pronto, a cara da criança ficaria mais ou menos assim:

Legal, não? E ainda dá pra fazer com que o FlexUnit4 exporte o resultado dos testes para um arquivo XML, permitindo que seus testes no Flex sejam importados pelo seu sistema de Integração Contínua, mas isso é assunto para outro post

Você pode baixar o código fonte aqui e ver os exemplos rodando online aqui.

Good testing!

Sem posts relacionados.

Testes unitários é um assunto muito comum hoje em dia entre desenvolvedores. Mas somente assunto, pois apenas 2% dos desenvolvedores escrevem testes. Depois de ler o post do Giovanni Bassi, eu queria saber: quanto desses 2% que escrevem testes para suas aplicações desenvolvem E escrevem testes em JavaScript?

É, acho que entrei num ponto crítico aqui. Nas minhas pesquisas sobre TDD , eu vi muita documentação para Java, .NET, Python, Ruby, PHP, Flex e Silverlight, mas é raro ver alguem falar de JavaScript. Será se são os devs que acham que JavaScript é coisa de menino ou é realmente difícil de testar apps em JS?

A dificuldade

Não há um único ambiente de testes para JavaScript. Há divergência entre os interpretadores que estão presentes em cada browser, o que nos obriga a testar em todos eles (ou pelo menos nos mais populares). IE, Firefox, Safari e Google Chrome são os mais comuns. Isso sem contar os browsers para Smartphones.

Imagine um desenvolvedor que esteja acostumado com o JUnit, NUnit, PHPUnit ou outros xUnit da vida, onde é necessário o mínimo de esforço para fazer testes. Agora imagine esse mesmo desenvolvedor abrindo 3 browsers diferentes e apertando F5 a cada vez que ele escreve um teste. Não tiro a razão de não testar JavaScript…. é simplesmente chato…

Há bibliotecas de teste que ajudam no desenvolvimento dos testes, como é o caso do js-test-driver, JSPec e JSUnit, por exemplo. Essas ferramentas têm recursos para fazer os testes rodarem em vários browsers através da linha de comando, mas todas elas possuem inconvenientes graves. O js-test-driver não suporta HTML fixtures, ou seja, se você quer testar alguma função em JavaScript que envolva manipulação do DOM, você terá que escrever o código HTML dentro do código JS. O JSUnit exige que você carregue cada caso de teste em JS dentro de um HTML. Além de ter de ficar escrevendo HTML toda hora na mão, ele não possui uma boa ferramenta de testes pela linha de comando. O JSPec parece funcionar muito bem. É o meu sonho de consumo atualmente: suporta fixtures, boa separação HTML/JS, Ajax Mocking, suporte à ferramentas de integração contínua e tem um conjunto de Shell Scripts que funcionam muito bem em um Unix. Somente em Unix.

A coisa é tão crítica que essa semana eu estava reparando isso na página do QUnit:

Quantos plugins que o jQuery tem? Vários, correto? Alguem pode explicar o porquê de somente o plugin de validação do jQuery ter testes decentes? Acho que isso ajuda a mostrar o quanto é difícil de testar JavaScript.

A solução e o futuro

Bem, no atual estado da arte das ferramentas de testes unitários de JavaScript, nós temos que nos sujeitar à uns procedimentos um tanto quanto chatos se quisermos testar nossas aplicações. Felizmente, há projetos muito ativos e muito bons que eu pude ver (js-test-driver e JSPec, principalmente) que estão avançando. Eu espero que o js-test-driver dê suporte a loading de HTML fixtures assim como o JSPec suporte plataformas Microsoft (sim, eu ainda desenvolvo em Windows) em um futuro próximo (assim como eu espero que eu cumpra a promessa de ajudar nesses projetos).

Você que está lendo esse texto já teve o mesmo tipo de experiência? O que achou? Conseguiu solucionar alguns dos problemas que eu citei aqui? Então saia do modo read-only e comente

Posts relacionados:

1. O que fazer quando seu codigo JavaScript se torna um monstro

Tá certo. A paródia da música dos Titãs não ficou boa. Mas acho que já deu pra sacar do que este post trata.

Enfrentar as matérias de programação na faculdade para quem já trabalha com desenvolvimento deve ser um saco para muita gente. Os professores geralmente não trabalham na área, não sacam nada além da linguagem e ainda tem coragem de nos fazer de trouxa, explicando como é a sintaxe da linguagem, como fazer algumas coisas básicas (leia-se CRUD) e acham que está tudo ok. Não está. Óbvio que não. Então, eu tenho algumas coisas a dizer para tais professores (e para os alunos também).

1 – Ensinar algumas coisas sobre a sintaxe e mostrar um CRUD não é o suficiente.

Precisamos mais além disso para desenvolver um trabalho final decente. Nós, alunos, precisamos aprender a nos virar, mas precisamos saber com o que devemos nos virar. Coisas básicas como indentação de código deveria ser cobrada. Separation of Concerns deveria ser incentivado e cobrado desde o início, por exemplo.

Não serei injusto. Algumas coisas como “comente seu código para documenta-lo” nos é ensinada. Isso é importante para quem está começando, pois saber se orientar dentro do próprio código é uma boa. Mas é algo insuficiente. Eles não ensinam como código pode ser autodocumentado, como bons nomes de variáveis podem ajudar nisso, como codificar “de cima para baixo” e outras coisas relacionadas a codificação.

2 – Nos passar trabalhos em grupo não necessariamente nos ensina a trabalhar como uma equipe.

Há vários trabalhos finais para fazermos e a forma mais fácil de fazer isso é deixar um para cada um. Dá pra eliminar vários problemas de comunicação e sincronização de código assim. Acho que já deu pra perceber que não aprendemos muito sobre ferramentas para desenvolvimento em equipe…

Quem for tentar desenvolver em equipe, provavelmente o fará enviando código por email, trocando pen-drives ou enviando via compartilhamento de arquivos, se tiver na mesma rede (impressionante, mas já vi “profissionais” trabalhando assim) e notarão o trabalho que isso dá. Obviamente, dá pra notar que não tivemos uma aula sobre controles de versão…

3 – O trabalho não acaba com a entrega…

Quem trabalha com desenvolvimento de software há um tempo sabe do que eu estou falando. De acordo com esse paper, mais de 90% dos custos de um software estão na sua manutenção. Vendo por esse lado, não estamos fazendo nem 10% do trabalho que deveríamos fazer.

Várias práticas de programação importantes são feitas durante a manutenção. Uma delas é a adição/mudança de recursos. Se fizéssemos isso, perceberíamos que coisas como refatoração e testes unitários são importantes.

4 – Metodologias são sempre bem vindas

Uma das dúvidas de quem começa a desenvolver é: como devo proceder, qual metodologia adotar. Um professor tem que ser um guia para um aluno escolher um método de trabalho. Praxis? XP? Scrum? PDCA? Sair fazendo na doida não é das melhores escolhas

Na matéria de Engenharia de Software, nós temos uma visão teórica de cada uma dessas metodologias. Uma matéria de programação com um projeto pra entregar poderia ser um cenário perfeito para coloca-las em prática.

5 – Conclusão

Matérias como essa são muito desperdiçadas na nossa universidade. E eu imagino que seja em outras também. Se você é professor, comece a pensar nisso e pense em como você pode ajudar a mudar o quadro aqui exposto. Se você é aluno, cobre isso do seu professor. Ou pelo menos tenha a boa vontade de estudar sozinho

Sem posts relacionados.

É com muito prazer que estou anunciando o nosso primeiro CodingDojo na Unimontes, sendo realizado pelo GWIB.
Mais detalhes no post do evento

Até lá!

Posts relacionados:

1. Streaming do Mare de Agilidade na Unimontes