Herberth Amaral Software development adventures

28Jan/100

Testes unitarios no Flex usando o FlexUnit 4

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!

  • Share/Bookmark
Tagged as: , , , , , , No Comments
27Jan/104

DojoMoc #5 – O mais emocionante de todos

Hoje nos reunimos na Unimontes para realização de mais um Coding Dojo. No total foram quatro pessoas:

  1. Diego Caxito
  2. Elvis (não, ele não morreu :)
  3. Diego Guimarães
  4. eu

A linguagem escolhida foi o JavaScript (\o/) e usamos o QUnit como suíte de testes. Apesar de todo o esforço do setup inicial do nosso caso de teste, o pessoal gostou bastante de fazer testes usando o QUnit.

O problema

Resolvemos escolher o problema na hora (inclusive, esse foi um dos motivos pelos quais nos atrasamos). O problema escolhido foi o A Diversion, um problema simples aparentemente, mas que nos deu um pouco de trabalho, principalmente na hora de explicar.

Os testes rodaram bem no Chrome 4 e no Internet Explorer 8. Como rodou no IE8, dá até pra considerar o código à prova de balas :)

Os testes possuem uma versão online disponível aqui. Pra quem quiser baixar, o link é esse.

A emoção

Tivemos que quebrar o problema principal em 3 problemas de menor tamanho para conseguirmos resolver. A última parte consistia em fazer um conversor decimal-binário na mão! Eu até tentei sugerir pra que pegássemos um pronto na net e focássemos mais na resolução do problema, mas a galera quis ser matuta. E foi bom assim, pois deixou o problema muito mais divertido.

Além do mais, é a primeira vez que trabalhamos com uma linguagem dinâmica no DojoMoc. Espero que se torne preferência da galera trabalhar com linguagens dinâmicas, pois, na minha opinião, facilita o trabalho.

Uma coisa que deu mais emoção ainda foi ter feito tudo usando o Notepad++ sem o langs.xml estar funcionando direito. Foi a primeira vez que não usamos uma IDE :D

E pra completar: dos 5 Dojos que fizemos até hoje, nós só conseguimos resolver o problema em duas vezes. O de hoje foi uma dessas vezes. Parabéns pra galera!

Não vai dar pra postar a nossa retrospectiva aqui agora porque os post-its ficaram com o Diego Caxito, mas em breve estaremos disponibilizando mais informações sobre o nosso Dojo de hoje no blog oficial.

É isso aí pessoal, até a próxima!

  • Share/Bookmark
Tagged as: , , , 4 Comments
24Jan/100

Como voce testa seu JavaScript?

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 :D

  • Share/Bookmark
Tagged as: , , , No Comments
31Dec/095

Banindo a procrastinacao: O Manifesto do Culto ao Pronto.

Procrastinação é a arte de enrolar. É o que te faz assistir aquele episódio da sua série favorita quando você tem um trabalho chato pra fazer. Infelizmente, não há como ser imune à procrastinação.  Todos nós procrastinamos, em um nível ou outro. Esse post trata sobre O manifesto do culto ao pronto, uma série de dicas e regras simples que visam diminuir o nosso nível de procrastinação.

Pra mim, a procrastinação aparece quando falta uma coisa: disciplina. Quando nossos pais ainda mandam no nosso nariz, eles nos fazem "andar na linha". Eles cobram, brigam e castigam para termos disciplina. Depois que crescemos, essa influência paternal impondo disciplina diminui, o que nos dá mais liberdade.

Aí que está o problema: nós não sabemos lidar com a liberdade. É muito bom saber que se pode fazer o que quiser quando quiser, mas será que estaremos realmente fazendo algo? Antes nós tínhamos nossos pais. Agora é quem? Por causa disso, precisamos de algumas regras para conseguirmos aproveitar a liberdade que nos foi dada de um jeito mais produtivo. Algumas dessas regras eu encontrei no The Cult Of Done Manifesto.

Vamos ao manifesto:

  1. Há três estados do ser: não saber, ação e realização.
  2. Aceite que tudo é um rascunho. Isso ajuda a terminar.
  3. Não há estágio de edição.
  4. Fingir que você sabe o que está fazendo é quase a mesma coisa de saber o que você está fazendo. Então aceite que você sabe o que está fazendo, mesmo que não saiba, e faça.
  5. Banir a procrastinação: se você demorar mais de uma semana para ao menos iniciar algo, descarte-o.
  6. O ponto de estar pronto não é pra terminar, mas para fazer outras coisas.
  7. Uma vez que você terminou uma tarefa, você pode descarta-la (e partir para próxima).
  8. Ria da perfeição. Ela é entediante e lhe impede de terminar as coisas.
  9. Pessoas sem as mãos sujas estão erradas. Fazer algo te torna certo.
  10. Falhas contam como pronto. Então cometa erros.
  11. Destruição é uma variação de pronto.
  12. Se você tem uma idéia e a publica na Internet, isso conta como um fantasma do pronto.
  13. Pronto é o motor de mais coisas prontas.

É um manifesto simples, mas que vai direto ao ponto. Ele levou 20 minutos para ser feito, pois os autores não tinham mais tempo para faze-lo.

Espero que todos tenham um 2010 com o mínimo de procrastinação possível :)

See ya.

  • Share/Bookmark
Tagged as: , , 5 Comments
21Dec/096

Foco e produtividade – A tecnica do Pomodoro.

O que?! Vai dizer que você caiu nessa denovo?

Quem nunca passou por uma situação parecida com essa aí de cima que jogue a primeira pedra!

1 - O problema

Esse tipo de situação acontece com muitos profissionais todos os dias. E, no meu ver, o principal problema é a liberdade. Digo, não a liberdade em si, mas o seu mau aproveitamento. Muitos de nós, profissionais de TI, não somos questionados sobre o que estamos acessando e que horas estamos acessando, desde que entreguemos tudo no prazo. Daí você já viu: hora extra, noites sem dormir e finais de semana em casa para cumprir com aquele prazo...

Várias metodologias foram criadas para sanar o problema da procrastinação. Uma delas é o famoso Getting Things Done (GTD) ou no seu título em português: A arte de fazer acontecer. O GTD tem seus pontos fortes e fracos. Dos pontos fortes, o principal é que ele fornece um "framework" para organização de vários níveis de tempo: desde de como vai ser cada hora do seu dia até planos para daqui dez anos. O ponto fraco é quase o mesmo que dá o ponto forte, pois, por ser um "framework", ele é genérico. A maioria das coisas que eu li nele são simplesmente frutos do bom senso comum.

2 - A Técnica do Pomodoro

A técnica do pomodoro é um pouco diferente. Ela é simplesmente prática, vai direto ao ponto e é bem simples: você trabalha 25 minutos, pausa 5, trabalha mais 25 e pausa mais 5 e assim por diante. Cada 25 minutos corresponde a um Pomodoro. Depois de 4 pomodoros, você pode fazer uma pausa maior (25 minutos).

Cada Pomodoro é indivisível, ou seja, você não olha seu Twitter, email, chat ou responde à sua mãe quando ela pede uma sugestão pro almoço durante estes 25 minutos. Totalmente focado no trabalho. A mágica da técnica do Pomodoro é que você sabe que você terá seus 5 minutinhos de descanso pra olhar seu Twitter, seu email, zuar o colega do lado e talvez até beber uma água (e esse tempo geralmente dá pra fazer isso tudo! Experiência própria.)

Essa explanação foi bem básica. Você pode conferir mais detalhes no livro disponível gratuitamente em PDF.

3 - Um pouco de história

A técnica foi criada por um sujeito italiano chamado Francesco Cirillo. O Francesco estava passando por maus bocados com os estudos pois ele não conseguia se concentrar nos estudos. Foi aí que ele olhou pra cima de sua geladeira, viu um Pomodoro (aqueles timers em forma de tomate que são usados na cozinha) e pensou consigo mesmo: "Será se eu consigo me concentrar só nisso durante 10 minutos?". Dito e feito. O sujeito pegou o timer, ajustou pra 10 minutos e desceu a lenha no livro. Wow! E ele conseguiu se concentrar por 10 minutos.

Vai um tomatinho aí?

O episódio descrito acima aconteceu em meados da década de 1980. De lá pra cá, ele vem experimentando diferentes timeboxes (diferentes tempos para o Pomodoro), também vem ministrando palestras e organizando workshops e chegou na conclusão que 25 minutos é o tempo que funciona bem para maioria das pessoas. Mas isso é somente um conselho, você pode colocar um timebox mais curto ou mais longo, dependendo da sua necessidade.

4 - Mãos à massa! Já!

Com o GTD você tem N desculpas para procrastinar. Com o Pomodoro não. São apenas 25 minutos, o que é que lhe custa? Teste por uma ou duas horas e veja qual foi o resultado.

Há pessoas que tem dificuldade (ou preguiça) de fazer a lista de tarefas e ainda sim utilizam a técnica do Pomodoro. Elas conseguem sucesso porque conseguem eliminar a ansiedade. Elas sabem que terão os 5 minutinhos pra fazer o que está em segundo plano e sabem que isso irá faze-las render no trabalho.

5 - Minha experiência

No início é cansativo. Os 25 minutos não parecem passar nunca e os 5 minutos são simplesmente muito curtos. Dá vontade de desistir. "Po, isso não é humano", pensei eu. Mas depois de dois dias de trabalho utilizando a técnica eu já consegui me acostumar.

Hoje eu tenho 4 meses de Pomodoro. Cinco minutos é tempo suficiente pra fazer muita coisa. De fato, 5 minutos hoje parecem mais suficiente para muita coisa. Eu tenho um nível de produtividade que eu invejável pelo Herberth de 4 ou 5 meses atrás, não sofro mais da ansiedade do email não lido ou do tweet não respondido, não tenho medo de ignorar o Google Talk (tem uma parte do livro que fala como lidar com interrupções, é bem interessante) e meu serviço rende bem mais.

O mais legal de tudo é quando as pessoas começam a sincronizar pomodoros. Além de divertido, essa forma de fazer as coisas ajuda para que você não desista.

6 - Timers para o Pomodoro

Bem, eu imagino que a maioria das pessoas que estão lendo esse post não tem um timer de cozinha. Então, há alguns programinhas legais para ajudar você a praticar a técnica do Pomodoro. Segue a lista de alguns deles:

(Essa lista pode aumentar. Comente esse post se você achar um que não está listado aqui).

Galera, acho que é isso. Bom Pomodoro pra vocês também!

P.S: Esse post foi escrito com 2 pomodoros e duas interrupções. Nesse meio tempo eu tive 14 tweets não lidos (thank you, ChromedBird), 4 emails a mais na minha caixa de entrada, duas conversas não respondidas no Google Talk e minha mãe realmente pediu uma sugestão para a janta :)

  • Share/Bookmark
Tagged as: , , , 6 Comments
10Dec/0910

“A gente nao quer so codigo… a gente quer codigo, controle de versao e bug track”

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 :)

  • Share/Bookmark
Tagged as: , , , , , , 10 Comments
7Dec/090

CodingDojo na Unimontes!

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

Até lá!

  • Share/Bookmark
Tagged as: , , , No Comments
   

Páginas

Categorias

Últimos Posts

Twitter

Comentários

Arquivo

Tag Cloud

Compadres

WCG