Testes Unit�rios em JavaScript Tutorial

Por que eu devo ler este artigo: Este artigo explicita isso trazendo a primeira de duas partes sobre o desenvolvimento de testes unit�rios usando JavaScript. Veremos todos os conceitos, pr�ticas e metodologias que norteiam o que h� de mais recente no assunto, assim como modelos b�sicos de como eles se aplicam ao uso do JavaScript e seus frameworks.

Nenhuma categoria do ciclo de vida de software est� em tanta evid�ncia quanto os testes unit�rios.

Guia do artigo:

Testes unit�rios
Design do teste
Tipos de teste
Tipos de processos
TDD
BDD
DDD
TDD x BDD
Ainda mais processos
Quando escrever testes unit�rios?
Teste Unit�rio em JavaScript
Escolhendo um Framework
qUnit
js-test-driver
Ambiente de Execuç�o dos Testes
Estrutura do C�digo
Objetos Mock
O que � teste unit�rio?
que � UML?
O que � TDD?
Testes e Frameworks
Escolhendo um framework de testes
Sintaxe
Caracter�sticas
Suporte
Ambiente
Execuç�o
Biblioteca de Testes
Construindo os testes
Testando a Manipulaç�o do DOM
YUI Library
JSTestDriver
Cursos de JavaScript
Curso de Introduç�o ao JavaScript
Aprenda JavaScript

Ao mesmo passo, o advento das tecnologias front-end, aliado aos processos e boas pr�ticas que cada vez mais se fazem necess�rios de serem aplicados a esse meio, trazem � tona a real necessidade de unir ambos universos: testes de unidade ao desenvolvimento client side.

No advento das tecnologias front-end e da utilizaç�o de novos padr�es de desenvolvimento, como a HTML5, novas f�rmulas e conceitos foram criados de forma a suprir a cada vez maior necessidade de atender a todos os diversos cen�rios de software.

O uso de testes unit�rios para verificar se um m�dulo ou unidade do c�digo est� funcionando corretamente como esperado j� n�o constitui nenhuma novidade. Afinal, tal conceito foi outrora introduzido na comunidade de desenvolvedores por Kent Beck, atrav�s de linguagens mais antigas como Smalltalk, C, C++ e at� mesmo no Java.

Por�m, se analisarmos bem o termo � sempre extremamente associado �s linguagens que se constituem �linguagens server side�, isto �, executam apenas do lado do servidor, muitas com processos bem definidos de compilaç�o, interpretaç�o, plataforma integrada ou multiplataforma, etc.

At� mesmo uma r�pida busca na web pelo termo ir� remeter em in�meras bibliografias, blogs e sites sobre o assunto com foco voltado para esse tipo de linguagem.

� interessante notar que at� mesmo o conceito foi desenvolvido e evolu�do sobre esse tipo de linguagem. Diante disso, este artigo visa construir uma ideia adaptada dos testes unit�rios para o universo front-end, especificamente focado no uso e construç�o dos exemplos em cima da linguagem de script mais famosa do mercado: JavaScript.

Logo, aqui abordaremos os t�picos mais famosos dos testes, desde os conceitos, teorias e boas pr�ticas, at� a escolha das ferramentas adequadas para tal.

Testes unit�rios

Antes de entender quais divis�es ou aplicaç�es de testes diversas existem no universo de programaç�o, � importante antes entender o que �, de fato, um teste unit�rio. O pr�prio nome j� consegue nos dizer muito acerca desse procedimento: um teste ou mais testes que verificam unidades de composiç�o de, no nosso caso, sistemas diversificados.

Se procurarmos mais formalmente, veremos algumas definiç�es mais elaboradas: �Em programaç�o de computadores, teste unit�rio ou teste de unidade constitui um m�todo de teste de software pelo qual unidades individuais de c�digo fonte, configuradas com um ou mais m�dulos de programas de computador juntos com dados de controle associados s�o testados para determinar se eles est�o aptos para o uso final.�

Se pensarmos programaticamente uma unidade de c�digo, e consequentemente de software, deve constituir o menor pedaço test�vel de uma aplicaç�o. Em linguagens orientadas a objetos isso pode representar um m�todo, ou at� mesmo um bloco menor de c�digo fonte.

Por�m, quando partimos para o paralelo das linguagens procedurais essa mesma unidade pode significar o m�dulo inteiro programado, mesmo sendo comuns as divis�es por m�dulos menores ou funç�es e procedures individuais.

Em resumo, os testes unit�rios nos permitem adentrar m�todos e classes para verificar a consist�ncia da implementaç�o dos mesmos. E isso significa que uma bateria de testes bem elaborada traz consigo uma carga de segurança alta em relaç�o ao c�digo implementado, uma vez que temos agora uma camada que seguramente avalia todas as unidades de c�digo quando da refatoraç�o ou alteraç�o dos mesmos.

Em outras palavras, � poss�vel introduzir novas partes ao c�digo existente (um m�todo, por exemplo) e poder verificar sua consist�ncia de igual forma.

Alguns desenvolvedores, no entanto, consideram que a pr�tica de escrever �c�digo para testar c�digo� constitui um desperd�cio de tempo, tempo este que poderia ser usada para focar nas pr�ximas iteraç�es de desenvolvimento, bugs, ou quaisquer atividades associadas.

Por�m, quando se trata do desenvolvimento de aplicaç�es, com v�rias pessoas trabalhando na mesma equipe (muitas delas alterando os mesmos pontos de c�digo), com v�rias iteraç�es, vers�es do c�digo e dependendo da complexidade do sistema, os testes unit�rios v�m para, na verdade, salvar tempo.

Basta considerar o mapeamento de erros que te deixaria r�pida e seguramente atualizar o c�digo fonte, por exemplo.

A ideia de testar partes do c�digo como um todo n�o � recente, data de meados de 1970, quando Kent Beck, um dos respons�veis tamb�m pela metodologia de desenvolvimento �gil XP (Extreme Programming), idealizou o conceito baseado na necessidade de mais produtividade quando da aplicaç�o de mudanças ao software durante o seu ciclo de vida.

A consolidaç�o, por�m, s� veio quando da criaç�o dos frameworks xUnit, que permitiam a verificaç�o de partes separadas do c�digo-fonte com os mesmos fins descritos at� ent�o.

Como o termo at� ent�o remetia apenas � linguagem Smalltalk, e com a popularizaç�o crescente do Java, tornou-se necess�rio ent�o a criaç�o de um framework para a linguagem, da� nasceu o famoso JUnit. Apesar de ser uma linguagem server side (no conceito de aplicaç�es cliente-servidor), o Java e o JUnit tiveram papel de extrema import�ncia para a popularizaç�o e aceitaç�o dos testes unit�rios por parte dos desenvolvedores de uma forma geral.

A partir dessa linguagem, foi que tivemos uma comunidade ativa e aberta � discuss�o do assunto, al�m de contribuir para a evoluç�o do conceito e respectivas implementaç�es.

Design do teste

Existem uma s�rie de propriedades a serem consideradas quando da criaç�o e utilizaç�o de testes unit�rios:

Ele deve ser automatizado e permitir repetiç�o;
Ele deve ser f�cil de implementar;
Uma vez escrito, ele deve ser mantido para usos futuros;
Qualquer um deve estar apto a execut�-lo;
Ele deve executar atrav�s do clique de um bot�o;
Ele deve executar rapidamente.

Com um teste unit�rio, o sistema sobre o teste (SUT) deve ser pequeno e apenas relevante para os desenvolvedores que trabalham proximamente ao c�digo. Um teste unit�rio deve considerar operaç�es do tipo: c�digo l�gico, c�digo que cont�m muitos branches, c�lculos or algo que de alguma forma requeira algum tipo de decis�o. Simples m�todos getters e setters s�o exemplos de c�digo n�o l�gico.

Quando um software � desenvolvido sob a perspectiva do teste unit�rio, a combinaç�o de escrever um teste unit�rio para especificar a interface mais o refactoring das atividades depois que o teste passa constituem o design formal do teste. Cada teste unit�rio pode ser visto como um elemento de design especificando classes, m�todos e comportamentos observ�veis. O teste exemplificado na Listagem 1 ilustra bem essa ideia.

Listagem 1. Exemplo de teste unit�rio em Java.


  public class AdicaoTeste {
   
      // pode somar n�meros positivos 1 e 1?
      public void testeSomaNumeroPositivoUmEUm() {
          Soma soma = new SomaImpl();
          assert(soma.add(1, 1) == 2);
      }
   
      // pode somar os n�meros positivos 1 e 2?
      public void testeSomaNumeroPositivoUmEDois() {
          Soma soma = new SomaImpl();
          assert(soma.add(1, 2) == 3);
      }
   
      // pode somar os n�meros positivos 2 e 2?
      public void testeSomaNumeroPositivoDoisEDois() {
          Soma soma = new SomaImpl();
          assert(soma.add(2, 2) == 4);
      }
   
      // O zero � neutro?
      public void testeSomaZeroNeutro() {
          Soma soma = new SomaImpl();
          assert(soma.add(0, 0) == 0);
      }
   
      // pode somar os n�meros negativos -1 e -2?
      public void testeSomaNumerosNegativos() {
          Soma soma = new SomaImpl();
          assert(soma.add(-1, -2) == -3);
      }
   
      // pode somar um n�mero positivo e um negativo?
      public void testeSomaPositivoENegativo() {
          Soma soma = new SomaImpl();
          assert(soma.add(-1, 1) == 0);
      }
   
      // E quanto aos n�meros grandes?
      public void testeSomaNumerosGrandes() {
          Soma soma = new SomaImpl();
          assert(soma.add(1234, 988) == 2222);
      }
  }
   
  interface Soma {
      int add(int a, int b);
  }
  class SomaImpl implements Soma {
      int add(int a, int b) {
          return a + b;
      }
  }

Na mesma listagem � poss�vel observar um conjunto de casos de teste que especificam um n�mero de elementos da implementaç�o. A interface Soma � respons�vel por manter o contrato de assinaturas de acordo com a sua classe de implementaç�o, SomaImpl. A implementaç�o verifica (assert) o comportamento de diferentes chamadas (situaç�es, casos) ao m�todo add().

Neste caso, os testes unit�rios, tendo sido escritos antes, atuam como um documento de design especificando a forma e comportamento de uma determinada soluç�o, mas n�o detalhes de implementaç�o, que ser�o deixados para o desenvolvedor.

Seguindo o paradigma �Faça a mais simples coisa que possa possivelmente funcionar�, a soluç�o mais f�cil que ir� fazer com que o teste passe est� na classe SomaImpl e interface Soma.

Ao contr�rio de outros m�todos de design, usar testes unit�rios como uma especificaç�o de design tem uma vantagem significativa: o documento de design pode ser usado para verificar se a implementaç�o �adere� ao design. Com esse m�todo de design os testes nunca passar�o se os desenvolvedores n�o implementarem a soluç�o de acordo com o design.

Tipos de teste

� extremamente importante saber a diferença entre os tipos de teste existentes, bem como suas nomenclaturas e conceitos. Existem tr�s divis�es principais de testes: o teste de unidade (que tratamos aqui), de integraç�o e de sistema. Vejamos as diferenças do teste de unidade para com as outras:

O teste de integraç�o, como o pr�prio nome j� diz, � o teste respons�vel por averiguar a integraç�o entre duas partes do seu sistema. Um dos exemplos mais cl�ssicos desse tipo de teste � representado pelo padr�o de projetos DAO, que faz acesso � base de dados para persistir as informaç�es manipuladas pela linguagem de programaç�o.

Ao desenvolver testes para uma classe desse tipo voc� automaticamente estar� criando um meio de verificar se a "integraç�o" entre ambos, c�digo e banco de dados, existe e est� conforme.

Existem v�rios outros tipos de integraç�es que podem ser verificadas via testes de integraç�o, tais como c�digo que se comunica com web services, que efetuam operaç�es de escrita e leitura sobre arquivos, que verificam a comunicaç�o ass�ncrona da implementaç�o de filas e JMS, ou at� mesmo que verificam o funcionamento de mensagens enviadas via sockets, por protocolos HTTP, etc.
O teste de sistema � uma express�o usada para designar se o funcionamento do sistema como um todo est� procedendo. O foco, portanto, deixar de ser a unidade (teste unit�rio) assim como a integraç�o (teste de integraç�o) e passa agora a focar na junç�o de todas as pequenas partes do sistema constituindo o conjunto completo de tarefas a serem executadas pelo sistema. Tamb�m chamado de "teste de caixa preta", esse tipo de teste lida com a averiguaç�o de tudo, desde o banco de dados, m�todos e classes at� as integraç�es.

Para algumas vertentes, os testes de aceitaç�o, que ficaram famosos com o advento do desenvolvimento �gil e s�o caracterizados pela aceitaç�o ou n�o do time �gil, s�o no final testes de sistema.

Diante dessa situaç�o, muitos desenvolvedores se perguntam qual tipo de teste escolher e/ou como associar cada n�vel de teste a uma situaç�o em espec�fico no ciclo de desenvolvimento do mundo real. Na verdade, n�o existe bala de prata, � preciso ter o discernimento de associar cada situaç�o a um tipo de teste espec�fico.

Por exemplo, as classes respons�veis por lidar com o neg�cio da aplicaç�o geralmente podem ser testadas em unidade, de uma maneira isolada, enquanto classes que se comunicam com web services necessitam de um teste de integraç�o aplicado, dada a necessidade do outro ambiente para tal teste. Al�m disso, vale frisar a import�ncia do teste bem feito, o que quase sempre significar� ter testes para ambas as situaç�es onde o teste funciona e quebra.

Tipos de processos

Al�m de analisar os tipos de testes que existem, � importante tamb�m saber a diferença entre estes e os diferentes tipos de processos de teste que existem e que envolvem todo esse ciclo. Essas famosas �pr�ticas de desenvolvimento� se dividem em tr�s nomes t�o famosos quanto: TDD - Test-Driven Development, BDD - Behavior-driven Design e DDD - Domain-driven Design (Figura 1).

Figura 1. Tr�s tipos de processos de desenvolvimento usando testes.

TDD

O TDD, Test-Driven Development (ou Desenvolvimento Orientado a Testes) � uma metodologia famosa que cresceu junto com o desenvolvimento �gil e que foca no lema "testar primeiro, desenvolver depois". Em outras palavras, � uma t�cnica que visa iteraç�es curtas e que prop�e que um dado desenvolvedor implemente primeiramente o caso de teste espec�fico para uma situaç�o de construç�o de funcionalidade, correç�o de bug, etc., e em seguida, e somente em seguida, crie o c�digo fonte que atender� e ser� validado pelo caso de teste feito anteriormente.

Ele ganhou mais atenç�o nos anos posteriores como diferentes metodologias junto ao processo de software que vinha surgindo. Dissecando o nome, desenvolvimento sugere um processo de pleno direito com a an�lise, projeto l�gico e f�sico, implementaç�o, teste, an�lise, integraç�o e implantaç�o, e orientado a testes implica o qu�o concreto os testes automatizados devem conduzir o processo de desenvolvimento. O TDD tamb�m � comumente chamado de programaç�o test-first.

Quando se houve falar sobre essa terminologia, principalmente associada a uma explicaç�o do seu conceito, a ideia � aparentemente simples. Apenas dando uma breve olhada na pr�pria palavra � poss�vel ver que TDD remete a ter testes que dirigem o desenvolvimento do software.

Se adentramos um pouco al�m na definiç�o desse conceito, nos deparamos com cinco diferentes est�gios:

Antes de qualquer coisa, o desenvolvedor escreve alguns testes;
O desenvolvedor ent�o executa alguns destes testes e (obviamente) eles ir�o falhar porque nenhuma destas features est�o de fato implementadas;
Em seguida, o desenvolvedor na verdade implementa todos os testes feitos antes, agora em c�digo fonte da linguagem escolhida;
Se o desenvolvedor escreve o seu c�digo bem, ent�o no pr�ximo est�gio ele ir� ver seus testes serem executados com sucesso;
O desenvolvedor pode agora refatorar seu c�digo, adicionar coment�rios, limpar o projeto de uma forma geral, como ele deseja porque o desenvolvedor sabe que se o c�digo novo quebrar em algum local, ent�o os testes ir�o alert�-lo sobre a falha.

O ciclo pode somente continuar se o desenvolvedor tem mais features a adicionar. Veja na Figura 2 a representaç�o desse fluxo.

Figura 2. Fluxo de execuç�o do TDD.

Vejamos um exemplo ent�o de como um desenvolvedor deveria fazer isso. Digamos que um desenvolvedor quer escrever uma funç�o que faz algo bem simples, como calcular um fatorial (obviamente um exemplo bem simples, mas isso ser� o suficiente para descrever como o comportamento TDD deva ser). A abordagem normal para TDD indica usar a funç�o e ent�o o assert para que o resultado satisfaça um determinado valor.

Os testes dever�o ser parecidos com o c�digo demonstrado na Listagem 2, totalmente desenvolvido sobre o framework JavaScript Mocha.

Listagem 2. Exemplo de TDD com JavaScript Mocha.


  var assert = require("assert"), fatorial = require("../index");
   
  suite("Teste", function (){
      setup(function (){
          // Cria quaisquer objetos que possam ser necess�rios
      });
   
      suite("#fatorial()", function (){
          test("igual a 1 para configuraç�es de tamanho zero", function (){
              assert.equal(1, fatorial(0));
          });
   
          test("igual a 1 para configuraç�es de tamanho um", function (){
              assert.equal(1, fatorial(1));
          });
   
          test("igual a 2 para configuraç�es de tamanho dois", function (){
              assert.equal(2, fatorial(2));
          });
   
          test("igual a 6 para configuraç�es de tamanho tr�s", function (){
              assert.equal(6, fatorial(3));
          });
      });
  });

Os testes com certeza falhar�o porque a funç�o ainda n�o foi escrita, mas � justamente essa a intenç�o: verificar como o comportamento do c�digo deveria funcionar, mesmo n�o tendo um c�digo ainda para testes. Agora que j� entendemos a abordagem nua e crua, criemos o c�digo da funç�o que ir� satisfazer os testes. Ele dever� se parecer com o c�digo representado pela Listagem 3.

Listagem 3. Resultado de comando de execuç�o do Java version.


  module.exports = function (val) {
      if (val < 0) {
            return NaN;
         }
      if (val === 0) {
            return 1;
         }
   
      return val * fatorial(val - 1);
  };

Agora se executarmos os testes, poderemos ver que todos eles passar�o com sucesso. Isso � como o TDD funciona.

Ao utilizar esse tipo de processo, alguns benef�cios se tornam claros logo j�, como o baixo acoplamento com uma s�rie de testes que comprovam o seu comportamento. Um dos resultados mais vis�veis do TDD � que os testes desenvolvidos sobre o mesmo fornecem uma esp�cie de documentaç�o informal do sistema, conforme falamos anteriormente, ditando n�o s� o que o sistema pode fazer mas tamb�m o que n�o deve fazer (e � a� onde entram os testes falhos).

Al�m disso, pelo simples fato de tudo isso estar integrado ao software, podemos dizer que o produto teste nunca ficar� ultrapassado, o que difere das atividades de escrita de documentaç�o e/ou comentar c�digo.

Alguns outros pr�s se fazem mais sutis, por�m importantes, no ciclo de vida do software bem como na ades�o de produtividade ao projeto, tais como a diminuiç�o do tempo usado para depurar c�digo, o que implicar� no lucro de tempo e, consequentemente, dinheiro.

Tudo isso � poss�vel pelo simples fato de o TDD informar a quem o usa sempre que um erro ocorrer no sistema, diminuindo o tempo de depuraç�o e deixando-a menos custosa.

BDD

O BDD foi primeiramente introduzido por Dan North no seu artigo "Instruç�o ao BDD" e � uma metodologia que evoluiu das pr�ticas de TDD. BDD � uma t�cnica de design sobre user stories, que deve ser escrita em uma linguagem intelig�vel por n�o-programadores.

Isso possibilita que todos os envolvidos no projeto, executivos, testers, usu�rios e outros funcion�rios a se tornarem mais ativos no desenvolvimento. As user stories s�o centradas na seguinte sintaxe:

T�tulo (uma linha descrevendo a hist�ria)

Narrativa:

Como um(a) [regra]

Eu quero [funcionalidade]

Que ent�o [beneficia]

Crit�rio de aceitaç�o: (apresentado como cen�rios)

Cen�rio 1: T�tulo

Dado um [contexto] e [mais alguns contextos]...

Quando [evento]

Ent�o [sa�da] e [outras sa�das]...

Como ocorre com o TDD, BDD � uma t�cnica de design outside-in. No BDD as hist�rias s�o escritas primeiro, ent�o verificadas e priorizadas pelos usu�rios e envolvidos n�o-t�cnicos. O programador ent�o cria o c�digo para atender �s hist�rias descritas. Em BDD, existem tr�s princ�pios-base:

Neg�cio e tecnologia devem referenciar o mesmo sistema da mesma forma;
Qualquer sistema deve ter um valor identificado e vari�vel para o neg�cio;
An�lises do tipo up-front, design e planejamento t�m um retorno cada vez menor.

O primeiro princ�pio base est� solidificado sobre a user story, escrita conforme mostramos acima, de uma maneira n�o-t�cnica. Essa noç�o de linguagem natural segue muitos frameworks BDD, mesmo em um n�vel de c�digo. O segundo princ�pio base de adicionar valor de neg�cio pode ser visto na hist�ria como a parte "Que ent�o [beneficia]".

O terceiro princ�pio tem o mesmo significado do processo TDD. Um design upfront � feito da forma mais pequena o poss�vel, mesmo que o design esteja indo por al�m do teste e refactoring.

Juntos os princ�pios ajudam os desenvolvedores a mitigar os riscos de criar recursos extra ou de criar funcionalidades de forma errada. At� hoje, o BDD n�o tem recebido tanta atenç�o na comunidade de pesquisas, mas isso provavelmente tenha relaç�o com a sua idade e sua origem de m�todo de pesquisa, o TDD, que ainda � alvo de muito contradiç�o.

Ok, podemos dizer que entendemos o que � BDD. Mas, � ainda brota algumas cl�ssicas e famosas confus�es. Alguns dizem que o BDD � similar ao TDD (fato que justifica ainda mais o porqu� de uma ter surgido a partir da outra), alguns outros ir�o dizer que � o mesmo que TDD por�m com alguns guidelines melhores, ou ainda que s�o abordagens totalmente diferentes para o desenvolvimento.

Independente da definiç�o, isso n�o importa muito. A principal coisa a se saber � que o "BDD � feito para eliminar problemas que o TDD venha a causar".

Em contraste ao TDD, o BDD consiste em escrever comportamento e especificaç�o que ent�o dirija o desenvolvimento do nosso software. Comportamento e especificaç�o devem ser vistos como similares para testes mas a diferença � deveras importante.

Vejamos, ent�o, novamente o problema descrito na seç�o anterior, quando fal�vamos sobre TDD, sobre escrever uma funç�o para calcular o valor fatorial de um n�mero (Listagem 4).

Listagem 4. Resultado de comando de execuç�o do Java version.


  var assert = require("assert"), fatorial = require("../index");
   
  describe("Teste", function (){
      before(function(){
          // Coisas a se fazer antes dos testes, como importaç�es
      });
   
      describe("#fatorial()", function (){
           test("igual a 1 para configuraç�es de tamanho zero", function (){
              assert.equal(1, fatorial(0));
          });
   
          test("igual a 1 para configuraç�es de tamanho um", function (){
              assert.equal(1, fatorial(1));
          });
   
          test("igual a 2 para configuraç�es de tamanho dois", function (){
              assert.equal(2, fatorial(2));
          });
   
          test("igual a 6 para configuraç�es de tamanho tr�s", function (){
              assert.equal(6, fatorial(3));
          });
      });
   
      after(function () {
          // Qualquer coisa a se fazer depois dos testes serem finalizados
      });
  });

A principal diferença � somente a escrita. O BDD usa um estilo mais verboso ent�o isso pode ser lido quase como uma sentença.

Isso � o mesmo que dizer que o BDD elimina problemas que o TDD venha a causar. A habilidade de ler seus testes como uma sentença � uma maneira mais cognitiva de como podemos pensar acerca dos mesmos testes. O argumento atua no "se voc� pode ler seus testes fluidamente, voc� naturalmente ir� escrev�-los de uma forma melhor e mais compreensiva".

Apesar de esse exemplo ser muito simples e n�o ilustrar totalmente isso, os testes BDD devem estar focados nas funcionalidades, e n�o nos resultados (essa tamb�m � uma das principais diferenças entre os dois). Frequentemente, voc� ouvir� que o BDD existe para ajudar no design do software, e n�o test�-lo como o TDD � suposto de fazer.

DDD

DDD, ou Domain-Driven Development, � um conjunto de padr�es e m�todos que focam na elaboraç�o de aplicaç�es que se caracterizam por refletir a cobrança compreendida e satisfat�ria de um neg�cio qualquer. Analisando sobre outra �tica, ele constitui uma inovaç�o na forma de formar qualquer pensamento sobre a pr�tica de desenvolvimento e seus m�todos.

O DDD lida com a construç�o de uma esp�cie de molde da realidade por inicialmente entend�-la por completo e s� depois p�r terminologia, regras e meio l�gico juntos de forma abstrata no c�digo fonte, o que comumente se chama de modelo de dom�nio.

N�o constitui nenhum framework ou ferramenta, mas sim uma esp�cie de plugin conceitual que pode ser acoplado ao projeto em qualquer momento.

O DD pode ser entendido tamb�m como uma forma de automatizar um neg�cio e seus processos, de forma que estejamos sempre focados no software em si para que s� assim o neg�cio seja atendido por completo.

� comum, inclusive, associar o desenvolvimento de softwares corporativos a essa ideia em espec�fico, mas o DDD vai al�m e mostra formas e padr�es de conceitualizar tudo isso em um modelo de dom�nio.

TDD x BDD

A situaç�o de ter de escolher entre TDD e BDD � complicada. Isso depende de haver ou n�o um framework de testes apropriado para a sua linguagem escolhida, o que os seus colegas de trabalho sentem em relaç�o ao mesmo, e dependendo da situaç�o muitos outros fatores entram na contagem.

Alguns defendem que o BDD � sempre melhor que o TDD porque ele tem a possibilidade de eliminar problemas que possam aparecer quando do uso do TDD.

A chave para o BDD � que ele pode prevenir esses problemas; isso n�o � garantido. Problemas como m� organizaç�o do c�digo, m�s pr�ticas de design, etc. sempre ir�o persistir. Voc� deixar� de ter de escrever testes ruins e em contrapartida ter� funcionalidades mais robustas.

Particularmente, nenhum dos estilos � melhor que o outro, isso realmente depende da situaç�o, e de quem usa. Algu�m que sabe como escrever �timos testes TDD pode ter alguns problemas como algu�m que sabe escrever �timos testes BDD. Se voc� se pegar escrevendo testes incompletos usando TDD e quiser um design de software melhor, ent�o d� uma chance ao BDD.

Ainda mais processos

Existem ainda algumas outras terminologias usadas para classificar outras vertentes de teste usadas como processos nos projetos �geis. Vejamos algumas delas abaixo:

FDD � Feature Driven Development (Desenvolvimento Guiado por Funcionalidades): O FDD � um tipo de teste feito para manter e criar projetos por interm�dio de uma lista de atividades simples, de forma a incentivar o desenvolvimento de novos c�digos, bem como compartilhar o conhecimento acerca dos mesmos. Isso permite, ent�o, a principal meta do FDD seja alcançada no ciclo de vida do software: resultados cont�nuos, funcionais e tang�veis.
ATDD � Acceptance test-driven development (Desenvolvimento Guiado por Testes de aceitaç�o): Conforme falamos anteriormente, esse tipo de teste comumente � confundido com os testes do tipo TDD, por causa da similaridade com que o desenvolvimento �gil associa os testes de aceitaç�o aos mesmos. Nesse tipo de teste, o trabalho est� totalmente direcionado aos testes de aceitaç�o, o que significa que pode haver uma analogia entre este e o TDD.

Quando escrever testes unit�rios?

N�s j� discutimos in�meros conceitos relacionados � utilizaç�o dos testes unit�rios at� aqui. Talvez a pergunta mais pertinente que possa surgir nesse momento, antes mesmo de entender e aceitar todos os conceitos at� ent�o apresentados, seja: Por que eu devo escrever testes unit�rios? Quando devo fazer isso?

Alguns desenvolvedores lidam com esse processo como mais uma pr�tica chata a ser seguida dentro dos processos de uma empresa. Mais ainda, talvez antes de se fazer tais perguntas, sejam necess�rios antes um contato inicial com o ato de escrever testes.

Somente assim, voc� ter� insumo suficiente para discernir se deve ou n�o escrever testes de unidade, e a�, ent�o, teremos a primeira pergunta respondida. Mas e quanto ao �quando�?

� f�cil para um gerente semi t�cnico dizer �escreva todos os testes do in�cio� (em alguns casos, dizer isso pra voc� mesmo ser� t�o f�cil quanto), mas a verdade � que voc� frequentemente n�o saber� quais s�o os pequenos componentes que s�o necess�rios quando apresentados juntos a um caso de uso de n�vel consider�vel.

� comum, por exemplo, que desenvolvedores façam os seus testes � medida que se vai desenvolvendo o c�digo, � medida que todos as �unidades� requeridas para implementar o caso de uso s�o feitas. Ao mesmo tempo, voc� estar� constantemente mudando funç�es sobre esse c�digo, refatorando e abstraindo tamb�m algumas partes, e tentando se antecipar ao que possivelmente ir� causar perda de tempo durante esse processo.

Consideremos o seguinte cen�rio: �como um usu�rio, ao logar na aplicaç�o voc� ser� levado para uma tela de menu principal�. Como podemos quebrar essa operaç�o gen�rica em unidades?

Imediatamente podemos selecionar o �login de formul�rio� como uma implementaç�o desse caso de uso que pode ser testada, e iremos adicionar algumas linhas de c�digo de teste requeridas para implementar essa funcionalidade corretamente (Listagem 5).

Listagem 5. Exemplo de divis�o dos passos para realizar o teste unit�rio.


  describe("login usu�rio", function() { 
    // cr�tico
    it("garanta que os endereços de email inv�lidos ser�o pegos", function() {});
    it("garanta que os endereços de email v�lidos ir�o passar da validaç�o", function() {});
    it("garanta que o formul�rio de submiss�o modifique o caminho padr�o", function() { });
   
    // � bom ter...
    it("garanta que o helper client-side helper seja exibido para campos vazios", function() { });
    it("garanta que ao pressionar enter no campo de senha envie o formul�rio", function() { });
  });

Dependendo das restriç�es implementadas, voc� deve decidir se deve ou n�o pular alguns passos, mas felizmente � poss�vel ver com facilidade o qu�o cr�tico s�o cada um deles, isto �, que se eles falharem podem bloquear o uso da aplicaç�o.

Um outro exemplo cl�ssico alusivo � o da construç�o de um carro. Para construir um carro do in�cio ao fim, cada parte que faz a motor, o chassi, os pneus, devem ser verificados individualmente para estar em ordem antes que elas possam de fato ser atreladas ao carro.

Se o tempo for dito insuficiente para averiguar todas estas peculiaridades, ent�o possivelmente peças importantes ser�o despriorizadas e poder�o n�o estar funcionando corretamente. Por exemplo, os pneus podem acabar n�o sendo verificados em relaç�o � press�o, a costura interior pode n�o ser verificada contra danos.

Isso pode resultar em um carro falho, mas isso n�o seria seu problema, aparentemente. Apenas uma dica: verifique com cautela o que pode ou n�o ser deixado de lado no momento de testar.

Teste Unit�rio em JavaScript

Essa � uma hist�ria de controv�rsias e recente. Apesar de JavaScript j� ocupar espaço consider�vel na comunidade de desenvolvimento front-end, inclusive at� quando comparada a outras linguagens de programaç�o mais famosas como o Java, C# ou PHP, sendo considerada refer�ncia como linguagem, o JavaScript ainda tem muito a evoluir junto a suas companheiras de lado (client side).

� muito f�cil, e comum, ignorar testes unit�rios quando se embarca em um projeto de grande escala que faz uso de JavaScript. Muitas vezes motivados pelo grande costume de desenvolver testes apenas no lado do servidor, uma vez que muitas das regras de validaç�o s�o sempre duplicadas em ambos os lados cliente e servidor.

Por�m, a necessidade de construir testes de unidade para JavaScript � t�o real quanto com quaisquer outras linguagens. As ferramentas e procedimentos de testes unit�rios, por sua vez, n�o s�o t�o claros para JavaScript quanto para as demais linguagens, o que acaba por construir uma imagem mais defensiva dos programadores para com o teste usando a linguagem de script.

O JavaScript vem de uma longa caminhada contra muitos conceitos, e anticonceitos. Houve um tempo onde ele era facilmente descartado, talvez adequado para validaç�es n�o-cr�ticas, mas n�o mais que isso. Ao longo dos anos, o pior obst�culo que programas feitos em JavaScript enfrentavam era sempre escrever aplicaç�es em larga escala, ou ao menos mitig�veis.

Com o tempo, os dialetos JavaScript foram ficando mais consistentes entre os browsers do que eram antes, e ferramentas como o jQuery podem ajudar a deixar essas diferenças (que ainda existem) ainda mais leves aos olhos dos desenvolvedores. Os debuggers finalmente alcançaram melhores patamares de qualidade, jamais vistos antes (sim, debugar JavaScript era terr�vel), atraindo, assim, o que antes afastava.

NOTA: O debug se tornou melhor ao longo do tempo, mas ainda depende do browser usado, pois cada fabricante define suas pr�prias ferramentas de depuraç�o.

Para todos os casos, com o advento da HTML5 e das plataformas mobile, o JavaScript est� se tornando cada vez menos ignor�vel. Aplicaç�es front-end inteiras est�o sendo desenvolvidas em JavaScript, e enquanto a ferramenta suporta defasagens antes escondidas em linguagens como Java e C#, isso significa que temos evolu�do.

E dentro desse escopo, uma �rea que permanece particularmente mudando, e que ir� começar a ficar incrivelmente importante nos projetos JavaScript de escopo crescente s�o os testes unit�rios.

Para ilustrar uma situaç�o mais pr�xima da programaç�o, vejamos um exemplo de funç�o b�sica em JavaScript, conforme o c�digo a seguir:


function
addQuatroAoNumero(num){

 return num + 4;

}

A mesma funç�o basicamente adiciona o valor 4, como um n�mero, � vari�vel passada por par�metro. Na Listagem 6 podemos verificar ent�o um poss�vel caso de teste para uma funç�o de execuç�o.

Listagem 6. Caso de teste para a funç�o addQuatroAoNumero().


  (function testAddQuatroAoNumero (){
      var num = 5, valorEsperado= 9;
      
      if (addQuatroAoNumero (num) === valorEsperado) {
          console.log("Passou!");
      } else {
          console.log("Falhou!");
      }
  }());

Ap�s passar o valor 5 para a funç�o sendo testada, o teste checa que o valor retornado � 9. Se o teste suceder, a mensagem �Passou!� � impressa no console de um browser moderno, caso contr�rio, a mensagem �Falhou!� aparecer�. Para executar este exemplo, voc� precisar� efetuar dois passos b�sicos:

Importar o arquivo js que cont�m o c�digo apresentado nas duas listagens anteriores.
Abrir a p�gina da Listagem 7 no browser.

Listagem 7. P�gina HTML para execuç�o do exemplo.


  <!DOCTYPE html>
  <html>
       <head>
           <meta http-equiv="Content-type" content="text/html; charset=utf-8">
           <title>Exemplo Teste Unit�rio JavaScript</title>
           <script type="text/javascript" src="js/script.js"></script>
       </head>
       <body></body>
  </html>

Ao inv�s de usar o console do browser para exibir os valores, voc� pode imprimir os mesmos dentro da p�gina ou dentro de uma janela pop-up atrav�s da funç�o alert() do pr�prio JavaScript.

Dentro do universo de teste unit�rio, os elementos usados para verificar se certa condiç�o � satisfeita s�o chamados de �assertions� (afirmaç�es). Na Listagem 6 o assertion est� concentrado na operaç�o:

addQuatroAoNumero (num) === valorEsperado

Para os casos em que se tem muitos assertions sendo feitos, � interessante fazer uso de um framework de teste unit�rio JavaScript para auxiliar.

Escolhendo um Framework

Se voc� desenvolve com Java, voc� provavelmente n�o perde muito tempo decidindo que framework de teste unit�rio ir� usar. O mais famoso deles, o jUnit, � sempre a opç�o preferida da maioria dos desenvolvedores por raz�es �bvias de qualidade. O panorama do JavaScript n�o � t�o resolvido assim, e que framework escolher pode afetar profundamente as suas capacidades de testes.

Vejamos pois alguns dos frameworks mais famosos para JavaScript, bem como suas particularidades que ajudar�o a analisar quando adotar um ou outro.

qUnit

O qUnit � um �timo candidato para começar. Antes de tudo, ele � consideravelmente f�cil de aprender. De in�cio pode ser um pouco complicado para entender alguns comportamentos que s�o menos intuitivos, mas assim que se entende os problemas por tr�s destes comportamentos tudo começa a fluir mais rapidamente.

Ele possibilita interaç�o com o DOM; voc� pode, por exemplo, identificar uma DIV na sua p�gina de teste para ser resetada para seu estado original entre os testes, promovendo assim atomicidade aos testes. Al�m disso, ele tamb�m prov� suporte a �testes ass�ncronos�, o que constitui uma funcionalidade vital para suas aplicaç�es.

js-test-driver

O js-test-driver foca no teste paralelo em m�ltiplos browsers. Ele tem sua pr�pria linguagem de casos de teste e assertions, distinta do qUnit. Existem projetos que possibilitam ambos de serem usados juntos, apesar de n�o existir um que suporte todas as capacidades de ambos frameworks.

Diferente do qUnit, ele n�o usa partes do DOM para relatar resultados e reinicia o DOM inteiro entre um teste e outro. Isso imp�e uma restriç�o a ser testada.

Ambiente de Execuç�o dos Testes

Essa � outra quest�o que parece muito mais complicada com JavaScript do que com Java: em qual ambiente devo executar meus testes?

Voc� deve sempre querer que o seu ambiente de teste seja compat�vel com o ambiente de produç�o o mais pr�ximo poss�vel. Mas para muitas aplicaç�es JavaScript, um pedaço cr�tico desse ambiente, o browser com seu respectivo motor JavaScript, � escolhido pelo usu�rio.

Mesmo se os problemas cross-browser (v�rios browsers) n�o forem t�o ruins quanto eles eram antes, ainda � muito imaturo dizer que um teste feito em um browser ter� um resultado consistente por al�m dos demais.

Ao mesmo tempo, testar em todos os diferentes browsers traz mais desafios quando voc� começar a pensar em testes automatizados e CI. Esse � o grande desafio que o js-test-driver � designado a resolver. Se voc� quer uma soluç�o puramente qUnit, voc� provavelmente ir� encontrar por si s� escrevendo seus pr�prios scripts ou fazendo sem automaç�o.

Existem v�rios ambientes de execuç�o JavaScript com suporte f�cil a scripts, como o NodeJE, por exemplo, que ser� muito �til para alguns testes automatizados de alto n�vel. Por�m, eles ter�o suas pr�prias limitaç�es (NodeJS n�o tem suporte a DOM nativo, apesar dos add-ons existirem) e em todo caso n�o conseguir� simular o comportamento do browser.

Uma abordagem multicamada deveria se aplicar melhor �s suas necessidades. Voc� poderia criar alguns scripts de teste para executar no NodeJS por CI, e ent�o rodar periodicamente uma su�te de testes em cada browser alvo. Alguns bugs dever�o n�o ser pegos como seriam se usasse uma CI completa.

Estrutura do C�digo

Nos prim�rdios do jUnit, n�o era incomum encontrar c�digo Java que n�o se dirigisse diretamente aos testes unit�rios. Ao longo dos anos, isso passou a ser visto como um teste de qualidade de um design. O JavaScript tem, como melhor, começado a desenvolver essa disciplina, e algumas das funcionalidades da linguagem que empurram os desenvolvedores Java na direç�o certa (como encapsulamento) n�o gozam do mesmo n�vel de suporte nativo no JavaScript.

Existem alguns frameworks que podem ajudar na escrita de testes unit�rios. O ExtJS, por exemplo, p�e um sistema de classes no topo do modelo de objetos do JavaScript. Ferramentas como essa podem ajudar se voc� as permitir, por�m como elas n�o fazem parte da linguagem, voc� pode sempre escolher ir contra as mesmas.

Escrever JavaScript test�vel �, e para o futuro continuar� sendo, uma arte a ser modelada de acordo com a pr�tica.

N�o � algo simples manter sempre o foco na testabilidade. Mesmo que voc� programa todas as linhas do seu c�digo com os olhos voltados para a testabilidade do mesmo, sempre aparecer�o determinados comportamentos no c�digo que fugir�o � regra, como ubiquidade ou comportamentos ass�ncronos.

Todo motor JavaScript � single-threaded, mesmo que algumas tarefas simples como requisitar um dado do servidor (usando Ajax, por exemplo), respondendo � chamada UI, ou explicitamente retardando uma atividade (atrav�s de um setTimeout ou setInterval), s�o todas feitas assincronamente.

Ent�o, o que um executor de testes deve fazer? Voc� � chamado a agrupar o c�digo que est� testando.

O framework � configurado para executar os testes;
O c�digo de teste configura pr�-condiç�es e faz uma chamada para o c�digo a ser testado;
O c�digo de teste checa os assertions;
O framework reporta os resultados e vai para o pr�ximo teste.

Mas e se o c�digo a ser testado faz alguma coisa de forma ass�ncrona? Ent�o, podemos verificar alguns outros passos espec�ficos:

O framework � configurado para executar os testes;
O c�digo de teste configura pr�-condiç�es e faz uma chamada para o c�digo a ser testado;
O c�digo a ser testado inicia algo, e ent�o ele chama alguma funç�o para finalizar a tarefa;
O framework reporta (imprecisamente) os resultados e vai para o pr�ximo teste;
Outras funç�es de fila devem executar;
A parte em fila do c�digo a ser testada recebe sua vez de executar, e finaliza a coisa toda que foi iniciada no passo 3;
O c�digo de teste verifica os assertions.

Dessa forma voc� consegue uma porç�o de testes falhando por uma raz�o n�o muito boa.

O qUnit endereça isso com a funç�o asyncronousTest(). Isso funciona apenas como a funç�o regular test(), exceto pelo fato do framework n�o assumir que o teste est� finalizado quando o c�digo de teste retorna. Voc� deve informar a ela quando o teste est� finalizado chamando a funç�o start().

Esse tipo de comportamento soa um pouco retr�grado. Voc� chama a funç�o start() quando voc� precisa finalizar o teste, porque isso diz ao framework para reiniciar o processamento. Esse mecanismo inteiro faz com que os testes executem em lockstep, o que parece que � s�ncrono, mas voc� pode chamar asyncronousTest() porque o nome referencia a natureza ass�ncrona do c�digo sendo testado.

Objetos Mock

A natureza din�mica do JavaScript traz, por sua vez, v�rios benef�cios e flexibilidades para escrever objetos mock, mesmo usando um framework de objetos mock.

Em Java, o seu objeto mock tem que compartilhar uma interface com, e/ou ser uma subclasse de, a classe que o substitui. Dependendo da sofisticaç�o do seu framework mock, isso pode impor v�rias restriç�es e/ou fazer com que o desenvolvedor pule alguns passos para ir direto ao trabalho pronto.

Em JavaScript, voc� pode criar um objeto que implemente exatamente o mesmo comportamento do mock. De certa forma isso tamb�m ajuda se o seu c�digo tiver sido escrito com algum tipo de invers�o de controle embutida, caso contr�rio ao menos voc� ir� se beneficiar com a forma f�cilo de interceptar uma funç�o chamada no JavaScript.

Desenvolver c�digo unit�rio n�o � uma tarefa simples, tampouco personaliz�vel e imediatista como muitos desenvolvedores a consideram. Exige conhecimentos acerca do processo, t�cnicas e intimidade com as ferramentas e processos envolvidos. Existe, sobretudo, experi�ncia que, por sua vez, s� pode ser adquirida com o tempo e o ac�mulo de situaç�es durante a vida como desenvolvedor.

Confira tamb�m

O que � teste unit�rio?

Curso

O que � UML?

Curso

O que � TDD?

Curso

Teste unit�rio para JavaScript, ent�o, � mais complicado de assimilar principalmente em vista do hist�rico que a linguagem traz consigo, n�o sendo considerada por muito tempo sequer para programaç�o b�sica, no at� ent�o advento das tecnologias server side.

Esse artigo � extremamente �til aos desenvolvedores que ainda t�m d�vidas tanto � opç�o por escrever testes unit�rios para c�digo JavaScript, como na hora de escolher um framework que atenda �s necessidades sempre t�o espec�ficas de cada projeto.

Atrav�s de exemplos pr�ticos examinaremos quais s�o as medidas mais adequadas para determinar qual framework melhor se encaixa na realidade de neg�cio de cada projeto, bem como analisaremos fatores muito importantes que diferem um framework de outro e o encaixam dentro de categorias espec�ficas. Veremos tamb�m como migrar o seu c�digo entre os mesmos frameworks, dadas as condiç�es de configuraç�o impostas por eles ante a conceitos como acoplamento, coes�o e otimizaç�o.

Desenvolvimento front-end e testes unit�rios s�o dois termos extremamente recentes no universo de desenvolvimento de software se comparados a tantos outros que j� est�o bem fixados e definidos no mesmo meio. E quando falamos em unir ambas as tecnologias, chegamos em um ponto, muitas vezes, definido como tabu: ser� que realmente funciona implementar testes unit�rios em ambientes, linguagens e plataformas front-end? A resposta � mais que sim.

Nesta segunda parte do curso vamos explorar os frameworks JavaScript de testes de unidade que fornecem os recursos e atalhos necess�rios para simplificar mais ainda o tempo de desenvolvimento.

Testes e Frameworks

Voc� provavelmente sabe que o teste � bom, mas o primeiro obst�culo a superar quando se tenta escrever testes de unidade para o c�digo do lado do cliente � a falta de quaisquer unidades reais. O c�digo JavaScript � escrito para cada p�gina de um site ou de cada m�dulo de uma aplicaç�o e est� intimamente misturado com a l�gica de back-end e HTML. No pior dos casos, o c�digo � completamente misturado com a HTML, como nos manipuladores de eventos in-line. Este � provavelmente o caso de quando nenhuma biblioteca JavaScript est� sendo usada para qualquer abstraç�o DOM. Escrever manipuladores de eventos em linha � muito mais f�cil do que usar as APIs DOM para vincular esses eventos. Mais e mais desenvolvedores est�o pegando uma biblioteca como jQuery para lidar com a abstraç�o do DOM, o que lhes permite mover os eventos in-line para os scripts espec�ficos, ambos na mesma p�gina ou at� mesmo em um arquivo JavaScript separado. No entanto, colocar o c�digo em arquivos separados n�o significa que ele est� pronto para ser testado como uma unidade.

Mas afinal, o que � uma unidade? Na melhor das hip�teses, � uma funç�o pura que voc� pode lidar de alguma forma: uma funç�o que sempre lhe d� o mesmo resultado para uma dada entrada. Isso faz com que o teste de unidade fique muito mais f�cil, mas na maior parte do tempo voc� precisar� lidar com os efeitos colaterais, que aqui significam manipulaç�es DOM.

De um jeito ou de outro, ainda � muito �til descobrir quais unidades podemos usar para estruturar o nosso c�digo e para construir testes de unidade em conformidade.

Escolhendo um framework de testes

Existe uma s�rie de propriedades a serem consideradas quando da escolha de um framework de testes, e este � um ponto extremamente necess�rio, pois tal escolha ir� influenciar na forma como se programa os testes, os limites que os mesmos ter�o (dentre os quais podemos encontrar limites de sintaxe, recursos, integraç�es, etc.), bem como outros fatores como documentaç�o, apoio da comunidade e principalmente a força do framework no que diz respeito � certeza de que ele n�o ser� descontinuado.

As IDEs JavaScript n�o oferecem a mesma ajuda como as IDEs para linguagens tipadas e est�ticas como o Java e o C#. Isso tamb�m impede a comunidade de padronizar uma estrutura de testes simples que possa oferecer recursos facilmente adapt�veis aos diferentes ambientes de execuç�o.

Al�m disso, a depuraç�o no passado sempre foi feita manualmente atrav�s de mensagens de alerta e extens�es do navegador como o Firebug, por exemplo. Para o TDD � importante que a linguagem e o ambiente suportem padr�es de teste, debug e refatoraç�o, afim de perceber os padr�es de projeto e teste como um todo.

Sintaxe

� medida que se investiga diferentes estruturas de teste, podemos notar que a sintaxe � um fator de diferenciaç�o em todos eles. Este fator � bem pessoal e realmente vai depender do que faz o desenvolvedor se sentir confort�vel quando est� utilizando uma ferramenta dessas. Isso vale n�o somente para frameworks de testes unit�rios, mas tamb�m para quaisquer tecnologias que façam uso de um c�digo de comunicaç�o, como linguagens de programaç�o, ferramentas de gerenciamento de redes, dentre outros exemplos poss�veis.

Por exemplo, o QUnit � mais que um framework de teste declarativo, pois sua API consiste de funç�es chamadas test, equals, strictEqual, deepEqual, etc.

Outra estrutura de teste, o Mocha, � mais parecido com o rspec (BOX 1) em que se l� de forma mais sentencial do que estrutural. Sua API consiste de funç�es chamadas describe, it, assert.equal, etc.

BOX 1. Rspec

� ferramenta de teste para a linguagem de programaç�o Ruby.Nascido sob a bandeira do Desenvolvimento Behaviour-Driven, ele � projetado para fazer desenvolvimento orientado a testes uma experi�ncia produtiva e agrad�vel.

A sintaxe de um framework � criada para suportar uma metodologia escolhida, que em teoria ser� o TDD ou BDD (vistos no primeiro artigo deste curso).

A sintaxe TDD � puro JavaScript com m�todos de biblioteca similares aos frameworks xUnit. Veja, por exemplo, o c�digo apresentado na Listagem 1 que exibe um exemplo no JSTestDriver. Repare que as sentenças assert s�o t�picas dessa sintaxe.

Listagem 1. Exemplo da sintaxe TDD com JSTestDriver.

TestCase (" FizzBuzzDevMedia ", {
    " test on 0 return 0": function () {
      var result = fizzbuzz (0) ;
      assertEquals (" Zero " ,0 , result ) ;
    }
  };

As sintaxes BDD s�o mais diversificadas, mas elas t�m em comum o fato de estarem mais pr�ximas de uma linguagem natural, j� que este � um dos princ�pios do BDD. Veja nas Listagens 2 e 3 dois exemplos de diferentes sintaxes BDD.

Listagem 2. Exemplos da sintaxe BDD com Jasmine e JSpec BDD DSL.

describe (" FizzBuzz ", function () {
   it(" return 0 on 0", function () {
      expect ( fizzbuzz (0) ) . toEqual (0) ;
   });
  });

Listagem 3. Exemplos da sintaxe BDD com JSpec BDD DSL.

describe �FizzBuzz �
   it �should return null on null �
     fizzbuzz (0) . should . equal 0
   end
  end

Na Listagem 2 n�s temos uma sintaxe JavaScript, mas os m�todos de biblioteca s�o nomeados muito proximamente aos princ�pios do BDD. A sentença assertEqual() antes usada na Listagem 1, agora se apresenta como expect().toEqual(), o que � mais leg�vel.

Na Listagem 3 temos uma DSL (Custom Domain-Specific Language) que pertence ao JSpec. Aqui, outro passo importante � tomado para traduzir para uma linguagem mais natural.

Caracter�sticas

Quando voc� começa a testar em JavaScript, vai rapidamente encontrarse em situaç�es onde precisa-se que o framework de teste ajude o desenvolvedor a testar certos casos de uso. Nesse mesmo universo, alguns termos caracter�sticos s�o usados para ajudar a identificar tais cen�rios. Por exemplo, vejamos a lista de terminologias a seguir:

Spies � S�o estruturas usadas para ajudar a detectar de onde o c�digo chamou uma determinada funç�o. Isso � �til para identificar a origem de erros e bugs que s�o encontrados no momento do teste;
Stubs � Os stubs s�o muito semelhantes aos spies, exceto pelo fato de que eles cont�m o comportamento j� pr�-definido. Por exemplo, suponha que se quer um m�todo que espie algum c�digo em espec�fico e quando o mesmo for chamado, retorne �abc�. Com os stubs esse tipo de comportamento � poss�vel;
�Servidor Fake � Os servidores fake servem para facilitar o processo de simulaç�o do envio de requisiç�es que seria feito em um servidor real. Obviamente, como se trata de JavaScript, a �nica forma de fazer isso seria usando AJAX. Se o c�digo emite chamadas AJAX e se quer falsificar a resposta da chamada AJAX, um servidor falso ir� ajud�-lo mais facilmente a testar isso;
Rel�gio Fake � Da mesma forma, podemos criar rel�gios fake para simular o comportamento do c�digo ante mudanças no rel�gio usado pelo ambiente para extrair valores como data, tempo, intervalos, contadores, etc. Se o c�digo reage de forma diferente baseado na data ou hora, ent�o um rel�gio falso ir� ajud�-lo a controlar exatamente qual � a hora, enquanto se faz os testes.

Suporte

O framework de teste � apoiado pela comunidade? Essa � uma das primeiras perguntas que se deve fazer quando se escolhe um. Por exemplo, o grunt (a ferramenta de ambiente de construç�o) suporta a execuç�o do QUnit em um servidor PhantomJS. Isto torna mais f�cil de escrever testes e t�-los executados automaticamente toda vez que se salvar o arquivo de teste.

Outra pergunta interessante � verificar se seria pr�tico excluir os arquivos do projeto quando n�o quiser mais us�-los? Isso facilitaria a vida no momento em que optasse por trocar de framework, migr�-lo ou at� mesmo combin�-lo com outros. Esse grau de granularidade determina se o framework � altamente acoplado ou n�o.

Ambiente

O ambiente de execuç�o mais comum para as aplicaç�es JavaScript � o browser, e em muitas situaç�es o pr�prio JavaScript depender� do objeto DOM dos browsers para executar de forma correta. Por�m, pode-se executar os seus testes em qualquer ambiente que simule todas as caracter�sticas de uma engine de browser para JavaScript.

A ideia da execuç�o fora do browser tornar o JavaScript mais �til tem ganhado popularidade � medida que as linguagens e aplicaç�es server-side tem ficado maiores e mais complexas. At� esse ponto, a l�gica interna das aplicaç�es pode ser verificada em um ambiente que simule o JavaScript como se ele estivesse no lado cliente da execuç�o ou um CMS (Content Management Systems), por exemplo, que ir� lidar com toda a comunicaç�o com o DOM por si s�.

Atualmente, o Mozilla suporta o Rhino, por exemplo, como uma engine JavaScript implementada em Java. O Rhino prov� uma execuç�o generalizada do modelo JavaScript sem a API do browser DOM, o que facilita os testes e torna o mesmo apto a ser usado como ambiente padr�o de testes.

Execuç�o

A principal diferença quando estamos falando sobre execuç�o dos testes, seria se o programador precisar consultar o browser ou se n�o receber nenhum resultado do mesmo. Efetuar um simples refresh na p�gina do navegador para cada teste executado � algo f�cil de implementar e configurar, mas n�o � r�pido e simples o suficiente como o processo do TDD dita.

O problema ir� crescer de acordo com o n�mero de navegadores que precisam executar os testes, uma vez que todos eles precisar�o ser abertos e recarregados automaticamente. A vantagem desse m�todo � a transpar�ncia oferecida, pois a biblioteca por si s� ser� um arquivo .js, facilitando o processo de exploraç�o e extens�o usando t�cnicas j� conhecidas. Muitos dos executores de testes utilizar�o esse tipo de teste in-browser, criando uma p�gina HTML onde os arquivos de teste de c�digo ser�o carregados atrav�s de tags script. Para bibliotecas de teste � poss�vel que programadores criem seus pr�prios testes in-browser atrav�s do uso de m�todos das mesmas bibliotecas.

A alternativa para esse tipo de estrat�gia � chamada de testes headless, que implica que os testes s�o executados a partir da linha de comando ou de dentro da IDE e os resultados s�o retornados para a interface. Eles podem ser executados em diferentes ambientes, alguns em Rhino, enquanto outros empurram os testes para um browser e exibem apenas os resultados retornados.

Por outro lado, esse tipo de teste pode ter mais demanda de configuraç�o com atenç�o especial para as configuraç�es locais de servidores e potenciais conex�es a browsers ou m�quinas remotas. Os arquivos de teste e c�digo precisam de certas configuraç�es para garantir as refer�ncias corretas e, em alguns casos, monitorar operaç�es de pesquisa para as alteraç�es de arquivos.

Biblioteca de Testes

A biblioteca de testes decide como o teste � feito, o que pode ser feito e como as demandas ser�o atreladas ao programador.

A biblioteca consiste de m�todos para determinar o ciclo de vida de configuraç�o, testes individuais, assim como agrupar os testes em su�tes. Ela tamb�m tem m�todos de comparaç�o, chamados de mecanismos de asserç�o no TDD e qualificadores no BDD, o que determina a sa�da dos testes. O alcance e cobertura dos m�todos de asserç�o e o ciclo de vida de configuraç�o entre as bibliotecas pode variar, mas em geral como eles ser�o constru�dos depende dos objetivos de design suportados pela metodologia usada.

Quando estes fatores s�o cobertos, uma biblioteca de testes pode adicionar funcionalidades para garantir um teste facilitado, alta legibilidade e menos repetiç�es para o desenvolvedor.

Com base em todos os fatores descritos, neste artigo iremos trabalhar essencialmente com tr�s frameworks de testes: o QUnit, o YUI Test e o JSTestDriver. Eles representam os tr�s frameworks mais usados e mais maduros em todos os fatores apresentados no momento, al�m de uma vasta documentaç�o e atualizaç�es constantes da comunidade.

Construindo os testes

Este artigo � para ajud�-lo com o problema mais dif�cil: extrair o c�digo existente e testar as partes importantes, descobrindo e corrigindo bugs no c�digo pelo meio do caminho.

O processo de extrair o c�digo e coloc�-lo em uma forma diferente, sem modificar o seu comportamento atual, � chamado de refatoraç�o (ou refactoring). O refactoring � um excelente m�todo de melhorar o design do c�digo de um programa, porque qualquer mudança realmente pode modificar o comportamento do mesmo, sendo mais seguro ent�o fazer somente quando os testes unit�rios estiverem prontos.

Este problema quer dizer que para adicionar testes ao c�digo existente voc� tem que correr o risco de quebrar as coisas. Ent�o, at� que voc� tenha cobertura s�lida com testes de unidade, voc� precisa continuar testando manualmente para minimizar esse risco.

Vejamos um exemplo pr�tico na Listagem 4 que exemplifica uma situaç�o onde temos um c�digo JavaScript b�sico com uma funç�o nossaData() que ir� receber um par�metro com a mesma data a ser processada. A funç�o, por sua vez, ir� capturar a data fornecida e verificar, atrav�s da criaç�o de um novo objeto de data atual, a diferença de tempo entre uma e outra. O resultado ser� impresso na vari�vel �diferença_dias� que ir� guardar a mensagem correspondente ao total da diferença calculada entre ambas as datas.

Listagem 4. Exemplos de c�digo de teste � busca por t�tulos.

<!DOCTYPE html>
  <html>
   <head>
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
      <title>Exemplos de data mutilados</title>
      <script>
      function nossaData(time){
          var data = new Date(time || ""),
              diff = ((new Date().getTime() - data.getTime()) / 1000),
              diferenca_dias = Math.floor(diff / 86400);
   
          if (isNaN(diferenca_dias) || diferenca_dias < 0 || diferenca_dias >= 31) {
              return;
          }
   
          return diferenca_dias == 0 && (
                  diff < 60 && "Agora" ||
                  diff < 120 && "1 minuto atr�s" ||
                  diff < 3600 && Math.floor( diff / 60 ) + " minutos atr�s" ||
                  diff < 7200 && "1 hora atr�s" ||
                  diff < 86400 && Math.floor( diff / 3600 ) + " houras atr�s") ||
              diferenca_dias == 1 && "Ontem" ||
              diferenca_dias < 7 && diferenca_dias + " dias atr�s" ||
              diferenca_dias < 31 && Math.ceil( diferenca_dias / 7 ) + " semanas atr�s";
      }
      window.onload = function(){
          var links = document.getElementsByTagName("a");
          for (var i = 0; i < links.length; i++) {
              if (links[i].title) {
                  var data = nossaData(links[i].title);
                  if (data) {
                      links[i].innerHTML = data;
                  }
              }
          }
      };
      </script>
   </head>
   <body>
         <ul>
         <li class="entry" id="post57">
               <p>abc abc acb acb �</p>
               <small class="extra">
                      Postado em <a href="/2014/12/abc/57/" title="2014-12-02T20:24:17Z">
                         02 de Dezembro de 2014</a>
                      por <a href="/john/">Sueila Valente</a>
               </small>
         </li>
         <!-- Mais itens -->
         </ul>
   </body>
  </html>

Se voc� executar esse exemplo, ver� um problema: nenhuma das datas s�o substitu�das. O c�digo funciona, no entanto ele percorre todas as �ncoras na p�gina e checa por uma propriedade de t�tulo em cada uma. Se n�o houver uma, ele passa para a funç�o nossaData(), e se ela retornar um resultado, ele atualiza o innerHTML do link com o resultado.

Al�m disso, temos um outro problema: para qualquer data anterior a 31 dias, a funç�o nossaData() apenas retornar� �undefined� (implicitamente, com um simples return), deixando o texto da �ncora como est�. Ent�o, para ver o que deveria acontecer, n�s podemos programar uma data hardcoded (fixa no c�digo). Veja na Listagem 5 o resultado da nossa p�gina ap�s as alteraç�es.

Listagem 5. C�digo de teste ap�s alteraç�es de data.

<!DOCTYPE html>
  <html>
   <head>
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
      <title>Exemplos de data mutilados</title>
      <script>
      function nossaData(time, time){
          var data = new Date(time || ""),
              diff = ((new Date().getTime() - data.getTime()) / 1000),
              diferenca_dias = Math.floor(diff / 86400);
   
          if (isNaN(diferenca_dias) || diferenca_dias < 0 || diferenca_dias >= 31) {
              return;
          }
   
          return diferenca_dias == 0 && (
                  diff < 60 && "Agora" ||
                  diff < 120 && "1 minuto atr�s" ||
                  diff < 3600 && Math.floor( diff / 60 ) + " minutos atr�s" ||
                  diff < 7200 && "1 hora atr�s" ||
                  diff < 86400 && Math.floor( diff / 3600 ) + " houras atr�s") ||
              diferenca_dias == 1 && "Ontem" ||
              diferenca_dias < 7 && diferenca_dias + " dias atr�s" ||
              diferenca_dias < 31 && Math.ceil( diferenca_dias / 7 ) + " semanas atr�s";
      }
      window.onload = function(){
          var links = document.getElementsByTagName("a");
          for (var i = 0; i < links.length; i++) {
              if (links[i].title) {
                  var data = nossaData("2014-12-02T20:24:17Z", links[i].title);
                  if (data) {
                      links[i].innerHTML = data;
                  }
              }
          }
      };
      </script>
   </head>
   <body>
         <ul>
         <li class="entry" id="post57">
               <p>abc abc acb acb �</p>
               <small class="extra">
                      Postado em <a href="/2014/12/abc/57/" title="2014-12-02T20:24:17Z">02 de Dezembro de 2014</a>
                      por <a href="/john/">Sueila Valente</a>
               </small>
         </li>
         <!-- Mais itens -->
         </ul>
   </body>
  </html>

Perceba que n�s mantemos o comportamento criado na Listagem 4, por�m com a adiç�o de uma data fixa na chamada da funç�o dentro do onLoad da p�gina. Essa adiç�o poder� ser feita quantas vezes forem necess�rias pelo testador-programador, de modo a atingir os diversos cen�rios de teste.

Agora, as ligaç�es devem dizer "2 horas atr�s", "Ontem" e assim por diante. Isso j� � alguma coisa, mas ainda n�o � uma unidade test�vel real. Mesmo que tudo isso funcione, qualquer pequena alteraç�o para a marcaç�o provavelmente quebrar� o teste, resultando em uma relaç�o custo-benef�cio muito ruim para um teste como esse.

Em vez disso, vamos refatorar o c�digo apenas o suficiente para ter algo que possamos testar a unidade.

Precisamos fazer duas mudanças para que isso aconteça:

passar a data atual para a funç�o nossaData() como argumento, em vez de ter que usar apenas new Date e;
extrair a funç�o para um arquivo separado, para que possamos incluir o c�digo em uma p�gina separada para os testes de unidade.

Remova o conte�do da tag script interna � tag head e adicione o mesmo em um novo arquivo .js. Logo ap�s, altere o nosso c�digo fonte para o que est� na Listagem 6.

Listagem 6. C�digo de teste refatorado.

<!DOCTYPE html>
  <html>
   <head>
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
      <title>Exemplos de data mutilados</title>
      <script src="nossadata.js"></script>
      <script>
      window.onload = function() {
          var links = document.getElementsByTagName("a");
          for ( var i = 0; i < links.length; i++ ) {
              if (links[i].title) {
                  var date = nossaData("2014-12-02T20:24:17Z", links[i].title);
                  if (date) {
                      links[i].innerHTML = date;
                  }
              }
          }
      };
      </script>
   </head>
   <body>
         <ul>
               <li class="entry" id="post57">
                      <p>abc abc acb acb �</p>
                      <small class="extra">
                             Postado em <a href="/2014/12/abc/57/" title="2014-12-02T20:24:17Z">02 de Dezembro de 2014</a>
                             por <a href="/john/">Sueila Valente</a>
                      </small>
               </li>
               <!-- Mais itens -->
         </ul>
   </body>
  </html>

Na listagem tem o c�digo com a melhoria expl�cita da adiç�o do tag de script que agora importa o arquivo de JavaScript dinamicamente quando a p�gina for executada. Com esta abordagem tamb�m n�o � preciso se preocupar com nenhuma mudança no HTML, pois o mesmo conseguir� enxergar as funç�es como antes.

Agora que temos algo para testar manualmente, vamos escrever alguns testes unit�rios e discutir logo em seguida, como mostra a Listagem 7.

Listagem 7. Testes de Unidade para o exemplo criado.

<!DOCTYPE html>
  <html>
   <head>
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
      <title>Exemplos de data mutilados</title>
      <script src="prettydate.js"></script>
      <script>
      function test(valor, esperado) {
          resultados.total++;
          var result = prettyDate("2014-12-02T22:25:00Z", valor);
          if (result !== esperado) {
              resultados.bad++;
              console.log("Esperado " + esperado + ", mas foi " + result);
          }
      }
      var resultados = {
          total: 0,
          bad: 0
      };
      test("2014/12/02 22:24:30", "Agora");
      test("2014/12/02 22:23:30", "1 minuto atr�s");
      test("2014/12/02 21:23:30", "1 hora atr�s");
      test("2014/12/01 22:23:30", "Ontem");
      test("2014/11/30 22:23:30", "2 dias atr�s");
      test("2014/11/26 22:23:30", undefined);
      console.log("De " + resultados.total + " testes, " + resultados.bad + " falharam, "
          + (resultados.total - resultados.bad) + " passaram.");
      </script>
   </head>
   <body>
         <!-- ... -->
   </body>
  </html>

Isto ir� criar um framework de testes ad-hoc, usando apenas o console para a sa�da. N�o tem nenhuma depend�ncia ao DOM em tudo, ent�o poderemos muito bem execut�-lo em um ambiente JavaScript n�o-navegador, como o Node.js ou Rhino, extraindo o c�digo na tag script para o seu pr�prio arquivo.

Se um teste falhar, ir� produzir o esperado e real resultado para esse teste. No final, ele vai mostrar um resumo do mesmo com o n�mero total de testes, os que falharam e os que foram bem-sucedidos.

Se todos os testes passarem voc� ver� o seguinte no console:

De 6 testes, 0 falhou, 6 passaram.

Para ver como uma asserç�o falha se parece, n�s podemos mudar alguma coisa no teste para quebr�-lo e ter algo como:

Esperado 2 dias atr�s, mas foi 2 dias atr�s.
  De 6 testes, 1 falhou, 5 passaram.

Embora essa abordagem ad-hoc seja interessante como uma prova de conceito (voc� realmente pode escrever um executor de teste em apenas algumas linhas de c�digo), � muito mais pr�tico usar um framework de testes unit�rios existente que proporciona uma melhor sa�da e mais infraestrutura para a escrita e organizaç�o de testes.

QUnit JavaScript

O QUnit � um framework JavaScript de testes unit�rios easy-to-use (f�cil para uso) poderoso. � usado pelo jQuery, jQuery UI e o projeto jQuery Mobile e � capaz de testar qualquer c�digo JavaScript gen�rico, incluindo o pr�prio.

Para usar o QUnit no seu projeto voc� precisa:

Baixar o arquivo qunit.css e o arquivo qunit.js (ver seç�o Links), diretamente do site oficial do projeto.
Criar uma p�gina HTML contendo tags espec�ficas que importam os arquivos de CSS e o JavaScript que voc� baixou.

Veja na Listagem 8 como ficaria o nosso c�digo de exemplo ap�s as devidas alteraç�es incluindo o QUnit.

Listagem 8. C�digo de exemplo ap�s inclus�o do QUnit.

<!DOCTYPE html>
  <html>
   <head>
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
      <title>Exemplos de data mutilados refatorados</title>
         
      <script src="nossadata.js"></script>
         <script src="qunit.js"></script>
      <script>
               test("nossadata basics", function() {
                      var now = "2014-12-02 22:25:00";
                      equal(nossaData(now, "2014/12/02 22:24:30", "Agora"));
                      equal(nossaData(now, "2014/12/02 22:23:30", "1 minuto atr�s"));
                      equal(nossaData(now, "2014/12/02 21:23:30", "1 hora atr�s"));
                      equal(nossaData(now, "2014/12/01 22:23:30", "Ontem"));
                      equal(nossaData(now, "2014/11/30 22:23:30", "2 dias atr�s"));
                      equal(nossaData(now, "2014/11/26 22:23:30", undefined));
               });
      </script>
   </head>
   <body>
      <div id="qunit"></div>
   </body>
  </html>

Junto com o clich� HTML de costume, temos tr�s arquivos inclu�dos: dois arquivos para o QUnit (qunit.css e qunit.js) e os nossadata.js anterior.

Ent�o, h� um outro bloco de script com os testes reais. O m�todo �test� � chamado uma vez, passando uma string como primeiro argumento (nomeaç�o do teste) e passando uma funç�o com o segundo argumento (que ir� executar o c�digo real para este teste). Este c�digo define o vari�vel �now�, que � reutilizada abaixo, e em seguida, chama o m�todo �equal� algumas vezes com argumentos variados. O m�todo de igualdade � uma das v�rias asserç�es que o QUnit oferece. O primeiro argumento � o resultado de uma chamada para nossaData(), com a vari�vel �now� como o primeiro par�metro e uma sequ�ncia de datas como segundo. O segundo argumento para �equal� � o resultado esperado. Se os dois argumentos para �equal� s�o o mesmo valor, ent�o a asserç�o vai passar; caso contr�rio, ela ir� falhar.

Finalmente, no elemento do corpo temos um c�digo espec�fico do QUnit. Estes elementos s�o opcionais. Se estiver presente, o QUnit ir� utiliz�-los para a sa�da dos resultados do teste, como podemos ver na Figura 1.

Figura 1. Resultado da execuç�o dos testes � Interface do QUnit.

Com uma execuç�o falha, ter�amos algo parecido com a Figura 2.

Figura 2. Resultado da execuç�o falha dos testes � Interface do QUnit.

Como o teste cont�m uma asserç�o falhando, o QUnit n�o esconde os resultados para esse teste e podemos ver imediatamente o que deu errado. Junto com a sa�da dos valores previstos e reais temos uma comparaç�o entre os dois, o que pode ser �til para a comparaç�o de sequ�ncias maiores. Aqui, � bastante �bvio que deu errado.

Continuando a fase de refactorings, as asserç�es est�o atualmente bastante incompletas, porque ainda n�o estamos testando as n semanas anteriores � variante. Antes de adicion�-lo, devemos considerar a refatoraç�o do c�digo de teste. Atualmente, estamos chamando nossaData() para cada afirmaç�o e passando o argumento now. Poder�amos facilmente refatorar isso em um m�todo de asserç�o customizado, como mostrado na Listagem 9.

Listagem 9. M�todo de assetion nossaData refatorado.

test("nossadata basics", function() {
      function date(then, expected) {
          equal(nossaData("2014/12/02 22:25:00", then), expected);
      }
      date("2014/12/02 22:24:30", "Agora"));
      date("2014/12/02 22:23:30", "1 minuto atr�s"));
      date("2014/12/02 21:23:30", "1 hora atr�s"));
      date("2014/12/01 22:23:30", "Ontem"));
      date("2014/11/30 22:23:30", "2 dias atr�s"));
      date("2014/11/26 22:23:30", undefined));
  });

Nessa listagem extra�mos a chamada para nossaData() na funç�o date, colocando a vari�vel now para dentro da funç�o. Terminamos com apenas os dados relevantes para cada afirmaç�o, tornando-se mais f�cil de ler, enquanto a abstraç�o subjacente permanece bastante �bvia.

Testando a Manipulaç�o do DOM

Agora que a funç�o nossaData() foi testada o suficiente, vamos focar um pouco no exemplo inicial. Ao longo das mudanças na funç�o nossaData(), o QUnit tamb�m selecionou alguns elementos do DOM e atualizou-os dentro do evento de load �window�. Aplicando os mesmos princ�pios de antes, n�s devemos estar aptos a refatorar o c�digo e test�-lo. Al�m disso, vamos introduzir um m�dulo para essas duas funç�es, para evitar desordenar o namespace global e para sermos capazes de dar a essas funç�es individuais nomes mais significativos.

Vejamos ent�o os c�digos representados nas Listagens 10 e 11, que retratam esse cen�rio de mudanças.

Listagem 10. Mudanças de nomenclaturas no c�digo.

<!DOCTYPE html>
  <html>
   <head>
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
      <title>Exemplos de data mutilados refatorados</title>
         
      <script src="nossadata.js" type="text/javascript"></script>
         <script src="qunit.js" type="text/javascript"></script>
         <link href="qunit.css" rel="stylesheet"/>
      <script>
               test("nossadata.format", function() {
                      function date(then, expected) {
                             equal(nossaData("2014/12/02 22:25:00", then), expected);
                      }
                      date("2014/12/02 22:24:30", "atr�sra"));
                      date("2014/12/02 22:23:30", "1 minuto atr�s"));
                      date("2014/12/02 21:23:30", "1 hora atr�s"));
                      date("2014/12/01 22:23:30", "Ontem"));
                      date("2014/11/30 22:23:30", "2 dias atr�s"));
                      date("2014/11/26 22:23:30", undefined));
               });
               
               test("nossaData.update", function() {
                      var links = document.getElementById("qunit-fixture").getElementsByTagName("a");
                      equal(links[0].innerHTML, "28 de Janeiro de 2008");
                      equal(links[2].innerHTML, "27 Janeiro de 2008");
                      nossaData.update("2014/12/02 22:25:00Z");
                      equal(links[0].innerHTML, "2 horas atr�s");
                      equal(links[2].innerHTML, "Ontem");
               });
   
               test("nossaData.update, one day later", function() {
                      var links = document.getElementById("qunit-fixture").getElementsByTagName("a");
                      equal(links[0].innerHTML, "28 de Janeiro de 2008");
                      equal(links[2].innerHTML, "27 de Janeiro de 2008");
                      nossaData.update("2014/12/02 22:25:00Z");
                      equal(links[0].innerHTML, "Ontem");
                      equal(links[2].innerHTML, "2 dias atr�s");
               });
               </script>
      </script>
    </head>
    <body>
      <div id="qunit"></div>
      <div id="qunit-fixture">
          <ul>
              <li class="entry" id="post57">
                  <p>abc abc acb acb �</p>
                  <small class="extra">
                                    Postado em <a href="/2014/12/abc/57/" title="2014-12-02T20:24:17Z">02 de Dezembro de 2014</a>
                                    por <a href="/john/">Sueila Valente</a>
                             </small>
              </li>
              <li class="entry" id="post57">
                  <p>abc abc acb acb �</p>
                  <small class="extra">
                                    Postado em <a href="/2014/12/abc/57/" title="2014-12-01T20:24:17Z">01 de Dezembro de 2014</a>
                                    por <a href="/john/">Sueila Valente</a>
                             </small>
              </li>
          </ul>
      </div>
   </body>
  </html>

Assim, as mudanças no arquivo nossadata.js resultam na Listagem 11.

Listagem 11. Mudanças de organizaç�o no c�digo JS do projeto.

var nossaData = {
      format: function(now, time){
          var date = new Date(time || ""),
              diff = (((new Date(now)).getTime() - date.getTime()) / 1000),
              day_diff = Math.floor(diff / 86400);
   
          if (isNaN(day_diff) || day_diff < 0 || day_diff >= 31) {
              return;
          }
   
          return day_diff === 0 && (
                  diff < 60 && "Agora" ||
                  diff < 120 && "1 minuto atr�s" ||
                  diff < 3600 && Math.floor( diff / 60 ) + " minutos atr�s" ||
                  diff < 7200 && "1 hora atr�s" ||
                  diff < 86400 && Math.floor( diff / 3600 ) + " horas atr�s") ||
              day_diff === 1 && "Ontem" ||
              day_diff < 7 && day_diff + " dias atr�s" ||
              day_diff < 31 && Math.ceil( day_diff / 7 ) + " semanas atr�s";
      },
   
      update: function(now) {
          var links = document.getElementsByTagName("a");
          for ( var i = 0; i < links.length; i++ ) {
              if (links[i].title) {
                  var date = nossaData.format(now, links[i].title);
                  if (date) {
                      links[i].innerHTML = date;
                  }
              }
          }
      }
  };

O resultado da execuç�o voc� pode conferir na Figura 3.

Figura 3. Resultado da execuç�o dos testes refatorados.

A nova funç�o nossaData.update � um extrato do exemplo inicial, mas com o argumento now para passar a nossaData.format. O teste baseado no QUnit para essa funç�o começa selecionando todos os elementos dentro de um elemento #qunit-fixture. Na marcaç�o atualizada no elemento do corpo, o

... � novo. Ele cont�m um extrato da marcaç�o de nosso exemplo inicial, o suficiente para escrever testes �teis. Ao coloc�-lo no elemento #qunit-fixture, voc� n�o precisa se preocupar com as mudanças do DOM de um teste afetando outros testes, porque o QUnit ir� reiniciar automaticamente a marcaç�o ap�s cada teste.

Vamos dar uma olhada no primeiro teste de nossaData.update: depois de selecionar essas �ncoras, duas asserç�es verificam se estes t�m os seus valores de texto iniciais. Posteriormente, nossaData.update � chamada, passando uma data fixa por par�metro (a mesma que nos testes anteriores). Depois, mais duas asserç�es s�o executadas, agora verificando se a propriedade innerHTML destes elementos t�m a data formatada corretamente, "2 horas atr�s" e "Ontem".

YUI Library

O Yahoo! User Interface Library (YUI) � uma biblioteca open-source feita em JavaScript para a construç�o de aplicaç�es web interativas ricas usando t�cnicas como Ajax, DHTML, e DOM scripting. O YUI inclui v�rios recursos do n�cleo do CSS e est� dispon�vel sob a licença BSD. O desenvolvimento do projeto começou em 2005 e algumas propriedades do Yahoo!, como o My Yahoo! e a p�gina Yahoo!, começaram a usar o YUI no ver�o daquele ano. Este foi liberado para uso p�blico em fevereiro de 2006. Foi desenvolvido ativamente por uma equipe central de engenheiros do Yahoo! e � hoje um projeto amplamente aceito e reconhecido pela comunidade.

O YUI Test, um componente dentro da biblioteca YUI, � um framework de testes unit�rios extenso e completo. Para começar com o YUI Test, voc� precisa:

Importar o YUI no cabeçalho da p�gina HTML, como se segue:

<script src="http://yui.yahooapis.com/3.18.1/build/yui/yui-min.js"></script>

No arquivo de script de teste, instanciar a funç�o YUI. Carregar os m�dulos necess�rios, test e console, como mostrado na Listagem 12.

Listagem 12. Carregar teste e console dos m�dulos YUI.

YUI().use("test", "console", function (Y) {
       // Casos de teste aqui
  });

Veja na seç�o Links o link necess�rio para efetuar o download do YUI Test. Estamos usando a vers�o 3.18.1, a mais recente na data de escrita deste artigo.

O m�dulo de teste � claramente necess�rio para fins de teste. O m�dulo de console n�o � obrigat�rio, mas o exemplo que faremos vai us�-lo para imprimir os resultados. Os casos de teste v�o dentro da chamada de retorno, com a inst�ncia Y global como argumento.

O YUI Test usa o construtor Y.Test.Case() para instanciar um novo caso de teste e o construtor Y.Test.Suite() para instanciar um conjunto de testes. Um conjunto de testes (ou su�te de testes), de forma semelhante ao JUnit, cont�m v�rios casos de teste. Voc� pode adicionar casos de teste para uma su�te de testes usando o m�todo add().

Crie uma nova p�gina HTML e adicione o c�digo a seguir nela:

YUI().use("test", "console", function (Y) {

Esse c�digo representa o reposit�rio web que responder� aos comportamentos de alguns testes.

Em seguida, crie um novo arquivo JavaScript e adicione o conte�do da Listagem 13. Nele podemos ver a adiç�o de algumas funç�es de mediç�o de temperatura e convers�o. Apenas funç�es b�sicas para simularmos os comportamentos no YUI Test.

Listagem 13. C�digo JavaScript das convers�es de temperatura.

function converterDeCelsiusParaFahrenheit(c){
      var f = c * (9/5) + 32;
      return f;
  }
   
  function converterDeFahrenheitParaCelsius(f){
      var c = (f - 32) * (5/9);
      return c;
  }

E por fim, crie um novo arquivo .js test_temp.js para guardar o c�digo de teste para as mesmas funç�es, como mostra a Listagem 14.

Listagem 14. Su�te de testes para as funç�es de convers�o.

module ("Convers�o de Temperatura")
   
  test("convers�o para F", function(){
      var actual1 = converterDeCelsiusParaFahrenheit(20);
      equal(actual1, 68, ?Valor n�o correto?);
         
      var actual2 = converterDeCelsiusParaFahrenheit(30);
      equal(actual2, 86, ?Valor n�o correto?);
  })
   
  test("convers�o para C", function(){
      var actual1 = converterDeFahrenheitParaCelsius(68);
      equal(actual1, 20, ?Valor n�o correto?);
   
      var actual2 = converterDeFahrenheitParaCelsius(86);
      equal(actual2, 30, ?Valor n�o correto?);
  })

Se estiver atento, ver� que o c�digo apresentado nessa listagem est� em QUnit. Isso quer dizer que a representaç�o dele aqui se dar� apenas com o objetivo de comparar os resultados e efeitos de implementaç�o em ambos os frameworks. N�o exibiremos o resultado no QUnit para n�o estender muito o artigo.

Agora vejamos como fica o nosso c�digo fonte usando o YUI Test. A Listagem 15 mostra como criar uma su�te e um caso de teste para o teste em quest�o usando o referido framework.

Listagem 15. Su�te de testes para funç�es de convers�o com o YUI Test.

YUI().use("test", "console", function (Y) {     
       var suite = new Y.Test.Suite("Su�te de Convers�o de Temperatura");
   
       // add o caso de teste
       suite.add(new Y.Test.Case({
               name: "Convers�o de Temperatura",
   
               setUp : function () {
                      this.celsius1 = 20;
                      this.celsius2 = 30;
                      
                      this.fahrenheit1 = 68;
                      this.fahrenheit2 = 86;
               },
   
               testConversaoCtoF: function () {
                      Y.Assert.areEqual(this.fahrenheit1, converterDeCelsiusParaFahrenheit(this.celsius1));
                      
                      Y.Assert.areEqual(this.fahrenheit2, converterDeCelsiusParaFahrenheit(this.celsius2));
               },
                      
               testConversaoFtoC: function () {
                      Y.Assert.areEqual(this.celsius1, converterDeFahrenheitParaCelsius(this.fahrenheit1));
                             
                      Y.Assert.areEqual(this.celsius2, converterDeFahrenheitParaCelsius(this.fahrenheit2));
               }
         }));
  });

Vejamos algumas observaç�es sobre a listagem:

O m�todo setup() est� dispon�vel. O YUI Test fornece os m�todos setup() e tearDown() a n�vel de caso de teste e su�te de testes.
Os nomes de m�todos começam com a palavra test e cont�m assertivas.
O exemplo utiliza o tipo de assertiva Y.Assert.areEqual(), que � semelhante � funç�o de equal() no QUnit.
O YUI Test oferece uma vasta gama de m�todos para asserç�es, tais como:
- Y.Assert.areSame(), que � o equivalente ao strictEqual() no QUnit.
- Tipo de dados assertivos: Y.Assert.isArray(), Y.Assert.isBoolean(), Y.Assert.isNumber(), e assim por diante.
- Asserç�es de valor especial: Y.Assert.isFalse(), Y.Assert.isNaN(), Y.Assert.isNull(), e assim por diante.

Para executar os testes no YUI Test use o objeto Y.Test.Runner. Voc� precisa adicionar casos de teste ou su�tes de teste a esse objeto e ent�o chamar o m�todo run() para rodar os testes. O c�digo a seguir mostra como fazer isso:

Y.Test.Runner.add(suite);
  Y.Test.Runner.run();

JSTestDriver

O JsTestDriver visa ajudar desenvolvedores JavaScript a usar boas pr�ticas de TDD e fazer testes de unidade de escrita t�o facilmente como o que j� existe hoje para Java com JUnit, por exemplo. Com a ferramenta poderosa JSTestDriver (JSTD) voc� pode executar JavaScript na linha de comando em v�rios navegadores. Ap�s baixar o JSTestDrver (ver seç�o Links) ele vem com um arquivo JAR que permite iniciar um servidor, capturar um ou v�rios navegadores, e executar testes nos navegadores. Voc� n�o precisa de um executor de HTML, como acontece com outros frameworks, mas � necess�rio um arquivo de configuraç�o. A Listagem 16 mostra um exemplo de arquivo de configuraç�o.

Listagem 16. Exemplo de arquivo de configuraç�o � jsTestDriver.conf.

server: http://localhost:4224
  load:
    - js/src/*.js
  test:
    - js/test/*.js

O arquivo de configuraç�o � escrito em YAML, que � um bom formato para arquivos de configuraç�o. Ele cont�m informaç�es sobre o servidor para executar, bem como a localizaç�o dos arquivos de c�digo fonte e teste.

Para executar os testes com JSTD basta:

Iniciar o servidor de teste. A partir da linha de comando, v� para a pasta onde o arquivo jsTestDriver.jar foi salvo e execute o seguinte comando:

java -jar JsTestDriver-1.3.3d.jar -port 4224

Listagem 16

Registre um ou v�rios navegadores para o servidor, copiando e colando a URL http:// localhost:4224/capture nos navegadores em teste.

Teste o mesmo c�digo fonte que voc� usou para os exemplos anteriores (convers�o de temperaturas), mas desta vez usando a sintaxe JSTD. A Listagem 17 mostra como converter os casos de teste a partir da Listagem 14 para o QUnit e da Listagem 15 para o YUI Test.

Listagem 17. Exemplo de arquivo de configuraç�o � jsTestDriver.conf.

TestCase("Convers�o de Temperatura", {
      setUp : function () {
          this.celsius1 = 20;
          this.celsius2 = 30;
         
          this.fahrenheit1 = 68;
          this.fahrenheit2 = 86;
      },
   
      testConversaoCtoF: function () {
          assertSame(this.fahrenheit1, converterDeCelsiusParaFahrenheit(this.celsius1));
          assertSame(this.fahrenheit2, converterDeCelsiusParaFahrenheit(this.celsius2));
      },
         
      testConversaoFtoC: function () {
          assertSame(this.celsius1, converterDeFahrenheitParaCelsius(this.fahrenheit1));
          assertSame(this.celsius2, converterDeFahrenheitParaCelsius(this.fahrenheit2));
      }
  });

O c�digo n�o � muito diferente da vers�o YUI. O JSTD usa a funç�o TestCase() para definir um caso de teste. � poss�vel definir pode definir os m�todos de teste usando uma declaraç�o in-line ou voc� pode estender o prot�tipo da inst�ncia TestCase. Os m�todos setup() e tearDown() est�o dispon�veis para cada caso de teste.

Para executar os testes, basta executar o seguinte comando:

java -jar JsTestDriver-1.3.3d.jar --tests all

A Figura 4 mostra o resultado da execuç�o destes testes.

Figura 4. Resultados dos testes JSTD.

O JSTD tamb�m se integra bem com o seu sistema de integraç�o cont�nua para fazer parte de sua construç�o cont�nua. Ele oferece integraç�o com IDEs como Eclipse (plug-in) ou TextMate (bundle).

Com o foco atual no lado do cliente das aplicaç�es web, os testes unit�rios com c�digo JavaScript tornaram-se essenciais. H� alguns frameworks que podem ajudar voc� a realizar seus objetivos, e este artigo analisou tr�s dos principais frameworks mais populares dispon�veis no mercado hoje: o QUnit, o YUI Test e o JSTestDriver.

Os frameworks que vimos aqui representam apenas uma pequena parte do universo de opç�es dispon�veis para testes de unidade. O mais importante � que voc� sempre entenda os conceitos para que assim possa aplica-los na pr�tica junto aos mesmos.

Existem in�meras outras possibilidades de melhoria para os c�digos aqui apresentados e voc� pode melhor�-los de diversas formas. Al�m disso, outros frameworks podem ser explorados dadas as suas condiç�es. Leia mais sobre os frameworks, faça testes e mais testes at� se sentir familiarizado com tais tecnologias. Com os fontes disponibilizados para download voc� ter� um material rico para avançar seus estudos na criaç�o de testes de unidade com JavaScript.

Testes unit�rios em JavaScript: Introdu��o

Neste artigo veremos como desenvolver testes unitários usando JavaScript e seus frameworks relacionados. Veremos todos os conceitos básicos de testes, suas diferenciações, aplicações, modelos, além de exemplos de código.

Guia do artigo:

Testes unit�rios

Design do teste

Tipos de teste

Tipos de processos

TDD

BDD

DDD

TDD x BDD

Ainda mais processos

Quando escrever testes unit�rios?

Teste Unit�rio em JavaScript

Escolhendo um Framework

qUnit

js-test-driver

Ambiente de Execuç�o dos Testes

Estrutura do C�digo

Objetos Mock

Confira tamb�m

O que � teste unit�rio?

O que � UML?

O que � TDD?

Testes e Frameworks

Escolhendo um framework de testes

Sintaxe

Caracter�sticas

Suporte

Ambiente

Execuç�o

Biblioteca de Testes

Construindo os testes

Testando a Manipulaç�o do DOM

YUI Library

JSTestDriver

Refer�nciais

Confira tamb�m

Cursos de JavaScript

Curso de Introduç�o ao JavaScript

Aprenda JavaScript

Artigos relacionados