Testando seu código

ReneRubalcava

<\/HEAD>

<\/P>

Você escreve apps incríveis<\/STRONG><\/EM>. Seus usuários estão felizes, você está feliz, tudo está ótimo<\/EM>. Alguém diz que quer alguns recursos novos. Você pensa cara radical, eu cuido disso<\/EM>. Você começa a escrever e refatorar, adicionando novos módulos, ajustando alguns outros e em algum momento toda a sua aplicação desaba. Algo quebrou e você fez tantas mudanças que não consegue dizer o que quebrou onde.<\/P><\/P>Você está ferrado.<\/STRONG><\/P><\/P>Talvez você nunca tenha passado por um cenário tão horrível, mas aposto que já teve que fazer algumas coisas feias no seu código para fazer as coisas funcionarem porque precisou contornar algum problema estranho que apareceu enquanto adicionava novos recursos.<\/P><\/P>A vergonha<\/H2>Como desenvolvedores, todos nós sentimos que deveríamos fazer isso. Talvez comecemos um novo projeto com entusiasmo fazendo isso. Devemos testar nosso código. Eu sou culpado de começar um projeto com muitos testes, mas em algum momento não mantenho isso e me sinto horrível por isso. Mas não precisa ser assim. Testes unitários<\/A> são apropriados para projetos grandes, confie em mim. Talvez seja TDD<\/A> ou BDD<\/A> ou você apenas escreve testes depois do fato. Seja como for, você só vai se agradecer no futuro conforme o projeto cresce.<\/P>

<\/P>

Aqui está um

repositório sobre testes<\/A> de Dev Summits anteriores da Esri e um exemplo legal de Karma<\/A>. Eu gosto do Karma, é um test runner legal, mas recentemente revisitei o TheIntern<\/A> para testes. Intern é realmente legal e você pode ler alguns posts realmente ótimos no SitePen<\/A> sobre ele. Confira o sobre InternRecorder<\/A> que é incrível.<\/P>

<\/P>

Simplifique seu fluxo<\/H2>A única desvantagem do Intern comparado a algo como Karma que eu nunca consegui fazer funcionar é fazê-lo rodar meus testes no terminal a cada alteração de arquivo, mas eu contornei isso usando live-reload<\/A> na minha caixa de ferramentas de desenvolvimento.<\/P>

<\/P>

Combine live-reload com

Grunt<\/A> e alguns plugins e toda vez que faço uma mudança no meu app, meu app recarrega no navegador e minha página de teste também recarrega para que eu possa ver instantaneamente se quebrei algo.<\/P>

<\/P>

<\/P>

<\/P>

Verde é uma cor linda.<\/P>

<\/P>

Agora não vou entrar na questão do

vermelho-verde-refatorar<\/A> do tdd ou teste unitário. Existem muitos tutoriais por aí para ajudar você com isso. Também há um mundo inteiro sobre spies e mocks para testes. Só vou dizer que gosto do SinonJS<\/A> para esse propósito. Eu conheço e estou acostumado com ele, mas outros podem ter preferências diferentes.<\/P>

<\/P>

Então como é um teste de exemplo? Talvez assim.<\/P>

define(function(require) {
  var registerSuite = require('intern!object');
  var expect = require('intern\/_chai!expect');
  var View = require('app\/_components\/_map\/_WebMapView');
  var topic = require('dojo\/_topic');
  var config = require('app\/_config');
  var utils = require('esri\/_arcgis\/_utils');
  var chai = require('intern\/_chai!');
  var sinon = require('sinon');
  var sinonChai = require('sinon-chai');
  chai.use(sinonChai);
  var mapView;
  registerSuite({
    name: 'components: WebMapView',
    setup: function() {
      \/\/- configurar teste aqui
      sinon.stub(utils, 'createMap').returns({
        then: function(){}
      });
    },
    beforeEach: function() {
      \/\/- executar antes
    },
    afterEach: function() {
      \/\/- executar depois
      if (mapView && mapView.destroy) {
        mapView.destroy();
      }
    },
    teardown: function() {
      \/\/- destruir widget
      utils.createMap.restore();
    },
    'Component is valid': function() {
      expect(View).to.not.be.undefined;
    },
    'View publishes a valid map given a webmapid': function() {
      mapView = new View({
        webmapid: config.webmap.webmapid
  &nbpsp;});
&nbpspexpect(mapView.webmapid).to.equal(config.webmap.webmapid);
&nbpsp}
&nbpsp});
});

Tudo esse barulho basicamente se resume a isto.

'View publishes a valid map given a webmapid': function() {
&nbpspmapView = new View({
&nbpsp&nbpspwebmapid: config.webmap.webmapid
&nbpsp});
&nbpspexpect(mapView.webmapid).to.equal(config.webmap.webmapid);
}

Basicamente estou dizendo que quando crio este componente, espero que ele tenha um webmap com o webmapid que dei ao construtor. É isso. A implementação fica por minha conta, mas o teste se preocupa apenas com o resultado final.

Conta uma história

Testes são ótima documentação. Não consigo contar quantas vezes abri os testes de uma biblioteca ou framework para entender melhor como usá-los quando estava confuso sobre algo na documentação. Eles podem ser recursos incrivelmente valiosos. Não substituem a documentação, mas são companheiros fantásticos.

Existem muitos tutoriais por aí sobre testes unitários em JavaScript para você ler. Muitos são baseados em QUnit ou Jasmine, mas como disse, aprendi a gostar muito do Intern. Intern integra bem com Sauce Labs, mas se você não precisa da plataforma completa, pode usar o driver local do selenium e o chromedriver. E se usar Grunt, posso usar o grunt-run para rodar o driver antes de executar os testes funcionais.

run: {
&nbpspoptions: {
&nbpsp&nbpspwait: false
&nbpsp},
&nbpspwebdriver: {
&nbpsp&nbpspcmd: 'java',
&nbpsp&nbpspargs: [
&nbpsp&nbpsp&nbpsp'-jar',
&nbpsp&nbpsp&nbpsp'tests/lib/selenium-server-standalone-2.46.0.jar',
&nbpsp&nbpsp&nbpsp'-Dwebdriver.chrome.driver=node_modules/chromedriver/bin/chromedriver'
&nbpsp&nbpsp]
&nbpsp}
}

Mas esses provavelmente são detalhes melhores deixados para um post futuro no blog.

Escreva alguns testes

No momento estou trabalhando em um gerador Yeoman para ajudar a simplificar isso para desenvolvimento ArcGIS JS API, que também inclui testes. Ainda não está totalmente pronto, mas espero terminar em breve.

Agora não estou dizendo que você tem que testar cada coisinha, mas é uma boa ideia testar o comportamento do seu app.

Dois pontos a considerar:

1. Escrever os testes antes - testar ajuda a guiar seu desenvolvimento.
2. Escrever os testes depois - pode ser feito, escrever o app pode ajudar a consolidar a ideia, mas você corre o risco de escrever testes apenas para passar.

Lembre-se que eu disse que os testes não se preocupam com as implementações do seu código. Você testa que passa a e espera resultado b. É isso. Então, é uma boa maneira de rapidamente anotar o que você está tentando realizar. Se você escrever os testes depois do fato, corre o risco de escrever os testes para se encaixar no seu código, que pode estar quebrado. MAS, se você rerodar esses testes enquanto escreve mais código, pelo menos saberá se quebrou algo que funcionava antes.

Existem muitos recursos sobre testes em JavaScript por aí. Aqui estão alguns que consigo lembrar.

Introdução ao Teste Unitário em JavaScript

Receitas de Testes em JavaScript

Intern Tutorial esri jsapi

Aqui está um projeto demo que inclui testes e ferramentas grunt para ajudar você.

Para mais dicas e truques geodev, confira meu blog.