Herberth Amaral

Parabéns! Você trabalhou de uma forma tão impressionantemente dura durante os últimos sete meses e meio neste projeto. Você atendeu à todas demandas do cliente que vieram. Você completou o projeto no prazo e dentro do orçamento de $30,000, economizando $2000. O cliente está muito satisfeito por isso. Você pode dizer isso pelos sinais de dólar nos olhos dele. O cliente também está satisfeito pois ele foi capaz de colocar o Website no ar para o mundo para crescer e conquista-lo, o website já tem alguns usuários vindos dos convites beta que você mandou no início da semana. Você ainda mantém contato com o cliente quase todo dia. Ele diz que o site está indo muito bem.

Mas.

Há um usuário que está reportando uma falha com uma funcionalidade que você implementou há três meses. O cliente configurou seu email para receber relatórios de bugs. Você os recebeu pouco tempo depois que o usuário mandou. Uma páginas está mostrando “Desculpe-nos mas algumas coisa deu errada”.

Uh oh.

Você entra no website e checa você mesmo. Certo o suficiente que a página está dando erro 500. Mas por quê? Essa funcionalidade foi concluída três meses atrás e funcionou bem, não foi? Você testou na sua máquina local e viu que talvez fosse algo simples. Talvez uma variável digitada incorretamente no controller. Ou talvez não. Talvez isso vai levar mais de dois segundos seus para identificar o problema. Talvez leve uma hora, um dia.

Uma semana.

Então como esse erro pode existir? Você escreveu testes, né?

Oh, eu entendo.

Por causa da deadline iminente você estava pressionado pelo tempo e não se incomodou em aprender nenhum dos frameworks de testes. Você quis aprender. Muitas pessoas falam sobre testes com uma atitude positiva… foi só você que não teve tempo. Quando você fala sobre o assunto, seu chefe diz “o cliente não está pagando para você escrever testes, ele está pagando para você escrever funcionalidades”. Mesmo seu conhecimento sobre Rails cresceu três ou quatro vezes, comparado com o que era antes, durante a vida deste projeto, você ainda não sabe merda nenhuma sobre testes. Talvez seja hora de aprender, você pensa. Ah, mas O Chefe não quer que você gaste seu tempo em coisas que não produzem funcionalidades. “Testes são um desperdício do dinheiro do cliente”, ele diz. Você suspira. “Eu irei fazer melhor no próximo projeto. Eu irei fazer com que ele veja a luz. Eu irei fazer testes de verdade…”, você diz na sua cabeça. Ok, então você não escreveu os testes.

Então aqui vão os fatos:

Há um bug.
Você trabalhou nele no passado.
Você precisa conserta-lo. Agora.
Então como você debuga este bug para garantir que ele não aconteça denovo? Bem, você o conserta e sabe que ele não irá acontecer denovo, certo? Você deixará um comentário decente (na verdade, você irá pensar em deixar um comentário decente) depois que estiver consertado, para que ninguem passe pelo mesmo erro. Certo?

Errado.

Tudo bem, então você sabe que está em algum lugar do passado. Você pode ver a lista de branches e talvez algum dispare um gatilho na sua memória, e você tem certeza que tem branches com nomes memoráveis?

Ah sim, branching no SVN é um pé no saco. Eu concordo. Se você pudesse ao menos convencer seu chefe a usar Git também. Branching no Git é muito mais legal. Talvez você fará que ele “veja a luz” sobre isso no próximo projeto também. Então todas as modificações são no trunk, e navegar regressivamente sobre ele vai, claro, levar bastante tempo. Boa sorte com isso.

Então vamos assumir que você passa pelo trunk. Você se lembra da revisão e conserta o bug. Feito. Morto. Destruído. Vencido. Manda para as profundezas do inferno com um oitavo da sua sanidade. Isso foi um pouco duro. Você escreve um teste de regressão para ter certeza que não irá acontecer denovo, certo?

Oh, eu entendo.

Você comentou no item a fazer do Basecamp dizendo que foi consertado. Eu acho que é um nome procurável, certo? Somente no caso de acontecer denovo. É chamado de “alguma coisa deu errdo” ou “A página está quebrada”?

Uh oh.

Então você vai pra casa, satisfeito que você deu um pé na bunda de um bug que esteve na sua mente por dias. Você venceu.

Parabéns.

Você acorda no dia seguinte, pega seu café/leite/suco de laranja e checa seus emails. Há três do facebook, uns dois de algumas listas de email que você está inscrito e catorze do seu cliente. Esses emails não são catorze cartas de amor. Você vê que o primeiro foi enviado para você 20 minutos depois que você foi pra cama. Se você pelo menos ficasse ficado até tarde…

Você lê o primeiro. É um relatório de erro. O próximo também. E o próximo depois desse também. E adivinha? O próximo também.

Todos os catorze emails que seu cliente enviou a você tarde da noite não foram “Obrigado por seu trabalho fabuloso no site”, eles tinham o linguajar parecido com “Por que essa merda está dando pau?”. Ele acha pagou uma boa grana nisso. Você está feliz sendo pago o quanto que você ganha. De qualquer forma, não faz muito tempo que você está fazendo isso e você tinha que iniciar de algum lugar. As pessoas cometem erros, né?

Parabéns.

Agora você tem alguns relatórios de bugs para lidar quando você chegar no trabalho pela manhã. Oito horas por dia, sendo que cada bug leva uns 30 minutos para consertar. Fácil, com tempo de sobra. “Pfft. Faço até o fim do dia”, você pensa. Você percebe que um dos relatórios de bug que foi enviado foi um bug que você consertou outro dia. Outro desenvolvedor trabalhando no seu projeto teve um conflito com o arquivo e acidentalmente colocou o código quebrado ao invés do código que estava funcionando. Ok, tudo bem. Você conserta denovo. Talvez você não tenha escrito aquele comentário e você irá inseri-lo aogra. Beleza, isso irá fazer com que eles parem de introduzir o bug denovo.

Há uma reunião de duas horas com outro cliente no início do dia, deixando você com apenas 6 horas para consertar aqueles bugs até o fim do dia. Você gasta meia hora a mais no almoço. Cinco horas e meia. Mas até o almoço você “matou” quatro deles. Você estava um pouco grogue nesta manhã e você achou que aquele almoço iria curar aquele sentimento. Você irá conquistar os outros dez nesta tarde.

Você não conquista.

Você terminou quatro, talvez cinco deles e deixou oito, talvez nove bugs consertados. O cliente não está satisfeito. Você fez apenas parte do trabalho. TODOS os bugs eram críticos. Sua empresa é pequena e você é o único com conhecimento do projeto, e, os outros desenvolvedores estão ocupados em seus próprios projetos. O cliente espera… DEMANDA… respostas 7 dias por semana, 24 horas por dia.

Por que você é a puta dele.

Tudo bem. Então seu chefe o envia um grande email de desculpas dizendo que você irá trabalhar duro no futuro para atender todas as demandas porque você não quer perder este cliente. Ele investiu $30,000 nesta empresa e com a versão 2 do site “pronta pra ir ao forno” ele irá investir bem mais.

Então você volta a corrigir aqueles bugs que faltam. Durante a noite mais três chegaram. O número de bugs agora é oito. Oito horas no dia, oito bugs na lista. Feitos até o fim do dia. Você completa cinco durante seu expediente e dois quando chega em casa, depois do jantar. Você está exausto. Eles levaram o dia todo para serem debugados. Você envia um email para o cliente dizendo que você consertou sete dos oito bugs. Ele te envia um email de volta, vinte minutos depois de você ter ido dormir, naturalmente, dizendo que o último bug “deixa o site inutilizável”. Seu chefe vem até você pela manhã e diz que seu trabalho não é bom o bastante. Você não aprecia muito a sugestão dele. Você reclama e diz que consertou treze dos catorze bugs que o cliente enviou no início da semana. Você sente que foi colocado num ritmo de trabalho excepcionalmente duro essa semana. Hoje você completou o décimo quarto, você está muito confiante sobre isso. Ele naturalmente pergunta o porquê de ter catorze bugs. Você não tem uma resposta imediata, embora você pensa em mencionar os testes. Ele continua com seu discurso retórico sobre aquilo que você deveria estar testando o código toda vez que você o coloca em produção. O seu chefe continua com a encheção de saco por uma hora. Você tenta contra argumentar os argumentos dele mas sua visão parece algo de um “ser superior” e pela sua falta de experiência você não pode colocar a culpa nele. Ele é o chefe no fim das contas. Ele chegou aqui de alguma forma. Ele tem que estar certo sobre tudo?

Sua empresa pagou todos estes débitos técnicos que você não tinha orçamento para tal. Todo o processo extra custou um mês a mais e o cliente estourou seu orçamento em $2000. $2000 que ele nunca quis gastar. Ao invés de economizar $2000, ele agora gastou $2000 extra da sua própria conta pessoal para fazer com que o projeto andasse. Ele está falando de deixar sua empresa e ir para uma que pode fazer um trabalho melhor. Este é provavelmente o caso. Seu chefe te chama no canto e te diz como está o projeto. O cliente está saindo. No próximo dia ele demite você.

Parabéns, Freebird. Você está sem emprego e com muito, muito pouco dinheiro. Uns $2000 é tudo o que você ainda tem. Hora de ir à caça denovo.

Então como você pode prevenir que algo assim aconteça?

Você eventualmente pega um novo emprego com uma nova empresa. Você se senta com o cliente e faz as coisas direito. Você cria specs das histórias de usuário usando algo parecido com o Pivotal Tracker. Você é ensinado a escrever testes religiosamente para cada história usando o Cucumber. Não há história sem um teste. Isso reduz o débito técnico a longo prazo Você não tem tantos bugs como você tinha quando não testava com as aplicações anteriores. Embora você ainda tenha alguns bugs, você não irá gastar todas aquelas longas noites os consertando porque você tem testes cobrindo todos eles. Os testes irão mostrar onde alguma coisa deu errado, pois, geralmente, uma parte defeituosa do site significa um teste que não está passando. Viu um bug que não foi coberto por uma história ou teste? Isso acontece algumas vezes, mas você agora tem esse framework fantástico que te dá certeza que não o mesmo erro não irá acontecer denovo: teste de regressão. Escreva o teste. Ele não passa. Conserte o bug. Ele agora passa. Se você ou seu time segue a regra Green is Good, então eles NUNCA MAIS irão reintroduzir este bug. Em teoria. Pessoas cometem erros.

Então você inicia uma história simples como “Login de usuário” e você escreve uma funcionalidade para o cucumber para ela com dois cenários. Um para login e outra para logout. Você escreveu todos os passos para ela mas alguns deles não estão implementados, outros estão quebrados. Isso é devido ao fato que você ainda não escreveu nenhum código para a funcionalidade ainda. Parece meio retrógrado e improdutivo à princípio. Isso é chamado de Desenvolvimento Orientado à Comportamento (Behaviour Driven Development – BDD). Você está aprendendo BDD e você irá fazer certo de agora pra frente. Você está se tornando um Jedi de BDD. Você implementa cada passo por vez e eventualmente sua funcionalidade está toda verde.

Pra que você faz isso?

Para que no futuro, daqui uns três meses, você não veja essa funcionalidade dando pau e não precise trabalhar numa máquina do tempo para voltar e dar um pé na sua bunda.

Você ainda ganha alguns pontos extra se você estiver usando um servidor de Integração Contínua para garantir que esta funcionalidade e seus eventuais irmãos de testes fiquem verde. Um build falho significa uma aplicação falha e seu único objetivo se aquele build está quebrado é fazer com que ele seja consertado.

Parabéns.

Agora você pode marcar como a história como “terminada” no Pivotal. Então você pode implanta-la num staging server e marca-la como “entregue”. Daí o cliente pode logar no no Pivotal e ver que a história está marcada como “entregue” e logar no staging server, testar a feature e apertar aquele amado santo-graal botão “Aceitar”. Você quer ver histórias verdes na sua lista do Pivotal. Verde é a cor que você quer ver em todo canto.

Verde é bom.

Então a próxima funcionalidade vem aí e envolve uma lógica de controller um pouco mais complexa que retorna um hash JSON. Você pode escrever isso em Cucumber, o você pode escrever um teste para seu controller com o RSpec. Este é o tipo de coisa que é realmente legal para discussões com o time. Você sugere o Jeito A de fazer isso, e talvez outra pessoa do do time irá concordar ou sugerir o Jeito B, e essa adorável dinâmica de discussão de idéias produz um resultado melhor. De qualquer forma, você irá escrever o teste primeiro e então o código. Behaviour Driven Development. Então o teste passa. Então você pode refatorar o código se ele ainda não estiver bom o bastante e ele ainda irá passar. Com certeza você irá se sentir mais devagar no início, mas o motivo disso é que você ainda está aprendendo como fazer. Não lute contra isso. Este tipo de coisa irá te poupar muito tempo no futuro, onde é mais importante. Foque-se mais nos ganhos a longo prazo do que a curto prazo.

Eventualmente depois dos sete meses e meio você terá todas aquelas histórias do Pivotal Tracker em verde na seção de “Concluída” e talvez um ou dois no “Backlog” que o cliente quer pronto apenas para a próxima entrega. Você irá rodar todas as specs no seu sistema. Todas elas estão verdes. Você irá rodar todas as funcionalidades. Elas estarão todas verdes. Você irá implantar no server de staging pela última vez nesta release. O cliente adora isso. Você implanta no server de produção e envia os convites. Todo mundo adora isso.

Mas.

Há um bug. Entretanto, desta vez você instalou algo tipo o Hoptoad para o erro ir para sua caixa de entrada na mesma hora que ele ocorre. Você é o time de suporte para esta aplicação, NÃO o cliente. Depois de tudo, você ainda está trabalhando numa empresa pequena. O relatório de erros contem uma stacktrace e você pode ver onde deu errado imediatamente. Você escreve um teste/funcionalidade para garantir que este bug jamais aconteça denovo. O teste falha, pois você ainda não consertou o bug. O erro é o mesmo reportado no email do Hoptoad. Você conserta o bug.

Parabéns. Você escreveu um teste de regressão para o bug com sucesso. Este bug jamais irá ocorrer pelo resto da vida do projeto.

O cliente está feliz. Seu chefe pergunta se o cliente pode bater um papo com você. Você está fazendo um trabalho excelente. Os outros caras tinham um salário maior que o seu porque você foi contratado como um desenvolvedor Junior. Não mais. Você percorreu um caminho surpreendentemente grande. Agora você é igual. O cliente quer que mais coisas sejam feitas na aplicação. O cliente está querendo que seu chefe vá até o escritório dele na próxima semana. Ele requisitou especificamente que você vá junto também, pois você parece estar “ligado”. Você se encontra com o cliente e discute os termos da próxima iteração, uma bem grande. O acordo avança e sua empresa precisa crescer. Massivamente. A aplicação explode, no sentido positivo. Você tem problemas com escalabilidade. Você contrata outros dez caras no próximo ano só para trabalhar nesta aplicação. Você e uns dois do time original os ensina tudo sobre sua aplicação e o processo que vocês desenvolveram. Então eles irão ensinar outras vinte pessoas que você irá contratar nos próximos seis meses.

Parabéns. Agora você está fazendo certo.

UPDATE

Este post é uma tradução do excelente post do Ryan Bigg. Thank you Ryan!

Notem que eu não coloquei nenhum link no texto. Como é um texto mais “educativo”, eu espero que as pessoas que o lerem tenham a iniciativa de pesquisar os termos desconhecidos por conta própria. Links são muito cômodos e não incentivam a pesquisa

Nos dias 20, 21 e 22 de maio de 2010, o Maré de Agilidade reúne em Belo Horizonte palestras, mini-cursos e workshops com a temática de metodologias ágeis. Participam do evento grandes nomes do segmento, sempre com o apoio de empresas e instituições de destaque no mercado de metodologias ágeis

Infelizmente, as vagas para o Maré de BH já estão esgotadas. Mas a boa notícia é que haverá o streaming do evento (da mesma forma que aconteceu com o Flex For Kids) na Unimontes!

Para participar é super simples: basta se inscrever no evento e apresentar o comprovante de pagamento no dia (sábado, 22 de Maio).

O streaming acontecerá na Unimontes, muito provavelmente no auditório do CCET (mesmo lugar do Flex For Kids. Poderá acontecer também na sala da Infobits, dependendo do número de participantes).

Viste a página oficial do evento e siga-os no Twitter para mais informações.

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!

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

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!

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

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.