Testes automatizados são uma ótima maneira de proteger seu código contra futuras regressões. Muitas pessoas estão familiarizadas com como fazer isso em nossa base de código Rails usando rspec, mas o lado do JavaScript pode ser um enigma para alguns.
Felizmente, nos dias de hoje, é bastante fácil adicionar testes básicos ao seu código Ember!
Testes de Componente
No tutorial anterior desta série, adicionamos um componente chamado fancy-snack para exibir nosso lanche com um fundo em fade. Vamos escrever um teste para ele. Crie o seguinte arquivo:
test/javascripts/components/snack-test.js
import componentTest from "helpers/component-test";
moduleForComponent("fancy-snack", { integration: true });
componentTest("test the rendering", {
template: "{{fancy-snack snack=testSnack}}",
setup() {
this.set("testSnack", {
name: "Potato Chips",
description: "Now with extra trans fat!",
});
},
test(assert) {
assert.equal(this.$(".fancy-snack-title h1").text(), "Potato Chips");
assert.equal(
this.$(".fancy-snack-description p").text(),
"Now with extra trans fat!"
);
},
});
Para executar o teste, abra seu navegador no servidor de desenvolvimento em /qunit?module=component%3Afancy-snack. Seu navegador executará então os testes de componente e exibirá algo como “2 asserções de 2 passaram, 0 falharam.”
Observe que, enquanto na página /qunit, você pode executar outros testes. Basta selecionar um novo teste na caixa suspensa Module no topo da tela.
Vamos passar pelo teste para entender como ele funciona.
A linha template diz ao Ember como gostaríamos de inserir nosso componente. É exatamente o mesmo markup que você usaria para colocar o componente em um template handlebars, então deve ser familiar:
template: '{{fancy-snack snack=testSnack}}',
Observe que ele está passando testSnack como o parâmetro snack. Isso é definido no método setup():
setup() {
this.set('testSnack', {
name: 'Potato Chips',
description: 'Now with extra trans fat!'
});
},
Eu apenas inseri alguns dados fictícios. É tudo o que precisamos fazer para que o Ember renderize o componente. Por fim, temos algumas asserções no método test():
test(assert) {
assert.equal(this.$('.fancy-snack-title h1').text(), 'Potato Chips');
assert.equal(this.$('.fancy-snack-description p').text(), 'Now with extra trans fat!');
}
Se você usar this.$(), obtém acesso a um seletor jQuery no seu template. As asserções aqui usam esse seletor para obter o valor do título do lanche e da descrição do lanche e compará-los com o que esperamos. Se os valores corresponderem, as asserções passarão e nosso teste estará funcionando.
Vale a pena notar que você não precisa testar cada pequena coisa em um componente assim. Você deve usar algum discernimento e tentar descobrir o que em seu código é provável de quebrar ou causar confusão para outros desenvolvedores no futuro. Se você testar muitas coisas no seu template, isso significará que será uma dor de cabeça para alguém no futuro alterá-lo. Comece pequeno, testando as coisas mais óbvias, e com o tempo você pegará o jeito.
Testes de Aceitação
Testes de aceitação são muitas vezes mais fáceis de escrever e podem ser mais poderosos do que testes de componente, pois testam seu aplicativo da mesma forma que um usuário faria em seu navegador. Eu geralmente começo com testes de aceitação e, se estiver criando um componente complicado, adiciono testes para ele também.
Aqui está como podemos escrever um teste de aceitação que visitará nossa rota /admin/snack e confirmará que o lanche foi renderizado:
test/javascripts/acceptance/snack-test.js
import { acceptance } from "helpers/qunit-helpers";
acceptance("Snack");
test("Visit Page", function (assert) {
visit("/admin/snack");
andThen(() => {
assert.ok(exists(".fancy-snack-title"), "the snack title is present");
});
});
O test() neste caso quase lê como inglês! O primeiro comando diz para visitar a URL de /admin/snack. Depois disso, há um método andThen(). Este método é necessário para garantir que todo o trabalho em segundo plano esteja concluído antes que os testes continuem. Como o código JavaScript e Ember é assíncrono, precisamos garantir que o Ember tenha concluído tudo o que precisa fazer antes que nossas asserções sejam executadas. Por fim, ele testa se o elemento .fancy-snack-title está presente.
No entanto, se você executar este teste visitando /qunit?module=Acceptance%3A%20Snack, verá que o teste falhará devido a um erro de AJAX.
Se você se lembra, nosso código inclui tanto um lado Rails quanto um lado JavaScript que executou uma requisição AJAX para obter seus dados. O teste de aceitação executou o lado JavaScript, mas não sabia o que fazer para obter seus dados do Rails.
Para corrigir isso, precisamos adicionar uma resposta falsa, usando a excelente biblioteca pretender. Abra o arquivo test/javascripts/helpers/create-pretender.js e procure pela linha que diz:
this.get("/admin/plugins", () => response({ plugins: [] }));
Logo abaixo, adicione uma linha para retornar um objeto de lanche falso para que nosso teste de aceitação funcione:
this.get("/admin/snack.json", () => {
return response({ name: "snack name", description: "snack description" });
});
Você pode ler o código acima como “para qualquer requisição a /admin/snack.json, responda com a seguinte response”.
Se você atualizar a URL /qunit?module=Acceptance%3A%20Snack, seu teste de aceitação deve recuperar seus dados via pretender e os testes devem passar.
Para onde ir a partir daqui
Você pode tentar construir um pequeno recurso e adicionar testes para garantir que ele funcione. Você pode até tentar usar TDD criando seus testes antes de escrever qualquer código no front-end. Dependendo do que você está trabalhando e de suas preferências pessoais, você pode achar isso uma maneira mais agradável de proceder. Boa sorte e feliz codificação 
Este documento é controlado por versão - sugira alterações no github.