Seções iMasters
JavaScript

Dicas para testes unitários em front end

A criação de programas complexos é apenas uma questão de dividi-los em unidades menores e depois juntá-las. O teste unitário é o teste dessas unidades menores. Mas se você ainda não escreveu testes unitários para o seu código, você deveria. Vale a pena o esforço. Eles ajudam você a pensar com as expectativas de seu código de uma forma organizada, minimizam o risco e o esforço ao mudar o código e incentivam o design modular – que tem seus próprios benefícios.

Este artigo vai guiar você  na direção certa para começar com testes unitários JavaScript no navegador, e vai te dar algumas dicas para ter certeza de que eles sejam executados da melhor forma possível .

Dica 1: Escolha um framework e comece

Existem frameworks de testes unitários bons o suficiente por aí que você não tem que construir o seu próprio. Se quiser uma recomendação, tente QUnit. É usado pela suíte de produtos do jQuery, é maduro, é fácil de usar e tem um excelente tutorial.

Se você é do tipo que gosta de opções, aqui estão algumas alternativas:

A coisa mais importante a fazer é escolher um, aprender a usá-lo, e então começar. Uma vez feito isso, você já realizou 98% do valor. Se você precisa d0s 2% extras, então vá em frente e gaste tempo descobrindo qual framework de teste serve melhor para você, embora não seja necessário.

Dica 2: Faça unidades

A ideia de teste unitário é testar uma pequena unidade autônoma de código antes de integrá-la ao sistema maior. Isso significa que você tem que ter unidades autônomas para testar o código com algumas dependências fora delas mesmas, se for o caso. Se você estiver escrevendo o código a partir do zero, o que significa escrevê-lo de uma maneira modularizada (loosely-coupled). Se o código já existe, é possível que seja necessário fazer uma certa quantidade de refatoração para tornar modular e de baixo acoplamento suficiente para adicionar testes unitários.

Um dos meus objetivos ao escrever testes unitários para o navegador é que eles são testáveis sem iniciar meu servidor de aplicação. Quero ser capaz de fazer teste unitário com, no máximo, um servidor web estático. Eu acho que é uma boa meta de se ter.

Dica 3: Crie novas páginas

O test harness para seus testes unitários do navegador é uma página web separada que inclui um arquivo JS contendo seus casos de teste. Embora não haja nenhuma regra rígida para saber como organizá-los, eu recomendo testar cada arquivo JS separado. Isso significa combinar cada um dos seus arquivos JS para outro contendo seus casos de teste, além de uma página HTML para aproveitar os casos de teste. Eu também gosto de ter uma página HTML principal para incluir todos os testes. Dessa forma, você pode executar todos eles antes de cada build/release, mas limitar apenas os testes para um módulo específico, enquanto você está ativamente fazendo alterações.

Sua estrutura de diretórios pode ser mais ou menos assim:

webapp
|- css/
|- img/
|- js/
|   |- menu.js
|   `- calendar.js
|- test/
|   |- allTests.html     /* includes all your test cases */
|   |- menuTest.html     /* includes menuTest.js test cases */
|   |- menuTest.js
|   |- calendarTest.html /* includes calendarTest.js test cases */
|   `- calendarTest.js
`- index.html

Dica 4: Aprenda como configurar o DOM

A maioria dos frameworks de testes unitários tem algum recurso para fazer algum trabalho de configuração antes e depois que a sua suíte de teste é executada, ou antes e depois que cada teste individual é executado. Isso é comumente conhecido como “setup” e “teardown”. É especialmente útil para testar ações que exigiam uma estrutura DOM específica, permitindo que você reinicie o DOM antes de cada teste.

QUnit ainda tem um recurso no qual você pode colar os elementos necessários do DOM em uma DIV com id=qunit-fixture, que se reinicia automaticamente antes de cada teste. Está descrito aqui.

Dica 5: Aprenda a lidar com solicitações AJAX

As solicitações AJAX e outras solicitações síncronas precisam de um tratamento especial. Você precisa indicar para o framework de teste que você vai executar um teste assíncrono e depois dar um sinal para ele quando o teste estiver completo. Caso contrário, o framework de teste iria saltar para o próximo teste, e possivelmente executar qualquer configuração e atividades de desmontagem prematuramente.

Testes assíncronos do QUnit se assemelham a isto:

asyncTest( "asynchronous test: one second later!", function() {
	expect( 1 );

	setTimeout(function() {
		ok( true, "Passed and ready to resume!" );
		start();
	}, 1000);
});

Dica 6: Respostas Stub Back End

Eu mencionei anteriormente que um dos meus objetivos ao escrever os testes unitários para o navegador é que eles são testáveis sem iniciar meu servidor de aplicação. Quero ser capaz de usar um servidor web simples e estático para fazer o meu teste. Ele contribui para um desenvolvimento mais rápido. Uma área que necessita de tratamento especial a esse respeito é a de solicitações HTTP.

Sem as respostas dinâmicas a partir de um servidor de aplicativos, eu faço stub nas respostas fazendo duas coisas:

  1. Fazendo mock todas as respostas estáticas que preciso para os meus casos de teste, e
  2. Fazendo a URL callback para os seus componentes configuráveis ​​em tempo real, para que possam ser apontadas as respostas stubbed no meio dos testes.

Próximos passos

Por hora, isso é tudo o que tenho a dizer sobre testes unitários no navegador. Então, o que você está esperando? Vá escolher um framework de teste e começar a trabalhar!

***

Artigo traduzido pela Redação iMasters, de Mike M. Lin. Publicado originalmente em http://www.joezimjs.com/javascript/tips-for-front-end-unit-testing/

Qual a sua opinião?