Desenvolvendo Plugins Discourse - Parte 6 - Adicionar testes de aceitação

Tutorial anterior: Developing Discourse Plugins - Part 5 - Add an admin interface


Você sabia que o Discourse tem duas grandes suítes de teste para sua base de código? No lado do servidor, nosso código Ruby tem uma suíte de testes que usa rspec. Para a aplicação do navegador, temos uma suíte qunit que inclui ember-testing.

Assumindo que você tenha um ambiente de desenvolvimento configurado, se você visitar o URL http://localhost:4200/tests, começará a executar a suíte de testes JavaScript no seu navegador. Um aspecto divertido é que você pode vê-la testando a aplicação em uma janela miniatura no canto inferior direito:

A aplicação Discourse é construída com muitos testes que começarão a ser executados quando você visitar o URL /tests. Portanto, pode ser útil filtrar seus testes pelo plugin em que você está trabalhando. Você pode fazer isso na interface clicando no menu suspenso Plugin e selecionando seu plugin:

Adicionando um Teste de Aceitação no seu Plugin

Primeiro, certifique-se de ter a versão mais recente do Discourse extraída. Ser capaz de executar testes de Aceitação a partir de plugins é um recurso relativamente novo e, se você não extrair a versão mais recente, seus testes não aparecerão.

Para este artigo, vou escrever um teste de aceitação para o plugin purple-tentacle que criamos na parte 5 desta série.

Adicionar um teste de aceitação é tão fácil quanto adicionar um arquivo ao seu plugin. Crie o seguinte:

test/javascripts/acceptance/purple-tentacle-test.js

import { acceptance, exists } from "discourse/tests/helpers/qunit-helpers";
import { click, visit } from "@ember/test-helpers";
import { test } from "qunit";

acceptance("Purple Tentacle", function (needs) {
  needs.settings({ purple_tentacle_enabled: true });
  needs.user();

  test("Purple tentacle button works", async function (assert) {
    await visit("/admin/plugins/purple-tentacle");
    assert.ok(exists("#show-tentacle"), "it shows the purple tentacle button");
    assert.ok(!exists(".tentacle"), "the tentacle is not shown yet");
    await click("#show-tentacle");
    assert.ok(exists(".tentacle"), "the tentacle wants to rule the world!");
  });
});

Eu tentei escrever o teste de uma forma clara, mas pode ser um pouco confuso se você nunca escreveu um teste de aceitação antes. Eu altamente recomendo que você leia a documentação do Ember sobre testes de aceitação, pois eles têm muitas informações ótimas.

Em cada teste que escrevemos, precisamos assert (afirmar) algo. Em nosso teste, queremos fazer algumas afirmações para verificar se o tentáculo está oculto inicialmente e só é mostrado após clicar no botão.

Queremos definir um conjunto de ações a serem tomadas antes que uma afirmação seja feita. Para fazer isso, usamos a palavra-chave await. Ao usar essa palavra-chave, esperamos que a execução de cada helper assíncrono termine primeiro.

Nossa primeira ação de importância é: await visit("/admin/plugins/purple-tentacle");. Isso diz ao nosso teste para navegar para aquele URL em nossa aplicação. Aquele URL era o que exibia o tentáculo.

Depois de visitar a página onde o botão do tentáculo roxo aparece, queremos verificar se conseguimos ver que o botão na página existe e que a imagem do tentáculo ainda não existe.

Isso é feito pelas seguintes afirmações:

assert.ok(exists("#show-tentacle"), "it shows the purple tentacle button");
assert.ok(!exists(".tentacle"), "the tentacle is not shown yet");

P.S. a versão anterior do plugin purple-tentacle não tinha o ID de elemento #show-tentacle no template handlebars. Verifique a versão mais recente para acompanhar!

Assim que esses testes passarem, é hora de testar a interação.

O próximo comando é await click('#show-tentacle');, que diz ao nosso framework de teste que queremos clicar no botão e mostrar o tentáculo.

Depois de simular um clique no botão, podemos verificar se o tentáculo aparece afirmando:

assert.ok(exists(".tentacle"), "the tentacle wants to rule the world!");

Não é tão ruim, certo? Você pode tentar o teste você mesmo visitando http://localhost:4200/tests?qunit_single_plugin=purple-tentacle&qunit_skip_core=1 em sua máquina de desenvolvimento. Você deverá ver muito rapidamente o tentáculo roxo aparecer e todos os testes passarão.

Se você quiser executar os testes qunit do plugin na linha de comando usando PhantomJS, você pode executar

rake plugin:qunit['purple-tentacle']

(onde purple-tentacle é o nome da pasta do seu plugin)

Depurando seus testes

À medida que você escreve seus plugins, seus testes podem ajudá-lo a identificar problemas no seu plugin. Quando você estiver desenvolvendo seus testes ou se fizer alterações no código do seu plugin, os testes podem falhar. Para ajudar a entender o porquê, o Ember tem alguns helpers legais: pauseTest() e resumeTest().

Para usá-los, adicione await pauseTest() dentro do código do seu teste onde você gostaria que o teste pausasse. Agora, quando você executa seu teste no navegador, o teste pausará automaticamente no ponto em que você adicionou pauseTest(). Isso lhe dará a chance de inspecionar a página ou ver quaisquer erros para ajudar a depurar problemas.

Para onde ir a partir daqui

Eu odeio soar como um disco arranhado, mas a documentação do Ember sobre testes é excelente. Você também pode querer ver como o Discourse testa várias funcionalidades navegando pelos testes em nosso diretório de testes javascript. Temos vários exemplos lá dos quais você pode aprender.

Bons testes!


Mais na série

Parte 1: Noções Básicas de Plugin
Parte 2: Plugin Outlets
Parte 3: Configurações do Site
Parte 4: Configuração do git
Parte 5: Interfaces de Administrador
Parte 6: Este tópico
Parte 7: Publique seu plugin


Este documento é controlado por versão - sugira alterações no github.

30 curtidas

OMG, have I put off writing tests for this long?!

A few things
I noticed you put an “id” into the template file that wasn’t there in the previous tutorial
I added 3 more tests to deal with the “Hide Tentacle” button I added
I needed to be logged in it is an Admin page
I needed to use port 4000 for my VirtualBox Vagrant set-up

Happily, quick success !

5 curtidas

I’ve noticed a push to implement testing for plugins lately and I completely agree that this is important. I’ve been terrible at writing these in the past and want to get caught up.

I was considering the setup of Travis CI on a plugin repo as I noticed the ability to use Docker with Travis. But having never touched Travis before, is it possible to do this with a plugin? It would be nice to submit PRs to my own repo and have the tests run automatically.

5 curtidas

how can I run single ember tests on the browser?

http://localhost:3000/qunit?module=Acceptance%3A%20Purple%20Tentacle

I mean, if I have another acceptance test called “another test”, how would I run it? Thank you!

If you click “rerun” beside a test, you’ll get a URL that is just for that particular test that you can refresh over and over.

You can also run by module by clicking in the “All Module” box and checking off just the modules you want to run.

2 curtidas

This tutorial needs updating to replace ok(...) with assert.ok(...).

Have put the necessary changes in a PR - I’m happy to edit the OP if it’s made into a wiki :slight_smile:

https://github.com/eviltrout/purple-tentacle/pull/2

2 curtidas

OK it is wikified! PM me if anything else needs this treatment any time.

1 curtida

A note after writing some basic acceptance tests for the Elections Plugin:

  • If you use the default loggedIn option, you’re logged in as eviltrout with the properties in this session fixture

  • You can login as a custom user (necessary if you’ve added custom user properties) by defining your own session fixture and setting it as the current user using the beforeEach hook. See here for an example.

@eviltrout is there a better way of using a custom user for acceptance tests?

5 curtidas

What we should probably do is change the acceptance method in discourse to take an argument for the user to log in as. Then your test could say { loggedIn: true, logInAs: angus }

If you’ve got time for that PR we’d accept it!

4 curtidas

q: how to run the ruby tests tests for a plugin?

i am trying to run the tests for discourse-github-linkback, but i have no idea how.

After some stackoverflow i tried this (and i got some errors):

~/discourse$ bundle exec rspec ./plugins/discourse-github-linkback/spec/lib/github_linkback_spec.rb 

An error occurred while loading ./plugins/discourse-github-linkback/spec/lib/github_linkback_spec.rb.
Failure/Error: CoreExt::ActiveSupport.without_bootsnap_cache { super }

NameError:
  uninitialized constant GithubLinkback
# ./plugins/discourse-github-linkback/spec/lib/github_linkback_spec.rb:3:in `<top (required)>'
# ------------------
# --- Caused by: ---
# NameError:
#   uninitialized constant GithubLinkback
#   ./plugins/discourse-github-linkback/spec/lib/github_linkback_spec.rb:3:in `<top (required)>'
No examples found.

Randomized with seed 60987


Finished in 0.02025 seconds (files took 3.36 seconds to load)
0 examples, 0 failures, 1 error occurred outside of examples

Randomized with seed 60987

Note that i see the plugin in the local discourse dev admin page, so i hope it is correctly installed (into ~discourse/plugins/

Simplest way, run bin/rake autospec, and save the file

1 curtida

From what i see, doing cd ~/discourse and then running

runs all the tests for discourse.

On my ubuntu 18.04 VM with i5 6500, this has been running for half an hour already.
It feels wrong to run the whole tests suite when i only want to run the tests in that one plugin.
(this is especially so when i probably will modify my tests again, at least a few times)

Did i do something wrong?

Let me guess, you are symlinking your plugin vs checking out directly to the path under plugins

nope,

tbp@tbp-linux-dev:~$ cd ~/discourse/plugins/
git clone -b allow-all-user-repositories-wildcard https://github.com/TheBestPessimist/discourse-github-linkback
tbp@tbp-linux-dev:~/discourse/plugins$ ll
total 40
drwxr-xr-x 10 tbp tbp 4096 mai 13 21:48 ./
drwxr-xr-x 20 tbp tbp 4096 mai 13 21:18 ../
drwxr-xr-x  6 tbp tbp 4096 mai 13 20:29 discourse-details/
drwxr-xr-x  6 tbp tbp 4096 mai 13 21:48 discourse-github-linkback/
drwxr-xr-x  6 tbp tbp 4096 mai 13 20:29 discourse-local-dates/
drwxr-xr-x  9 tbp tbp 4096 mai 13 20:29 discourse-narrative-bot/
drwxr-xr-x  7 tbp tbp 4096 mai 13 20:29 discourse-nginx-performance-report/
drwxr-xr-x  5 tbp tbp 4096 mai 13 20:29 discourse-presence/
drwxr-xr-x  3 tbp tbp 4096 mai 13 20:29 lazyYT/
drwxr-xr-x  9 tbp tbp 4096 mai 13 20:29 poll/
tbp@tbp-linux-dev:~/discourse/plugins$ 

Can you confirm you tried saving the spec file once it was running, cause it is meant to interrupt stuff and start running the plugin spec?

since the initial bin/rake autospec is still running, there was/is no “save spec file” message yet.
also, by running bin/rake autospec --help, i saw no --save option.

I didn’t understand what save the file meant, so my full command was bin/rake autospec > spec.rb ← probably this is wrong

I meant in Vim or whatever you use, save the spec file, there is a watcher on it that will invoke the spec runner once it is saved.

Also see: How do I run only discourse/plugins/poll/spec?

1 curtida

Finally i did it :^).

With the help of that link, i ran the tests by using this command:
bundle exec rake plugin:spec["discourse-github-linkback"]
and, ofc, i was in ~/discourse when doing that.

Thanks for all your help @sam!

(1st PR for discourse-plugin babyyyyy :tada:)

8 curtidas

My Qunit-Tests aren’t executed or at least they don’t show me any output.
They finish with the following:

No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#Build-times-out-because-no-output-was-received

Travis.CI Result - Travis CI
Test-File - GitHub - kokoro-ko/discourse-humble-box: humble-bundle onebox

I am not that skilled with CI yet and haven’t found my mistake by now.

Do your tests pass if you visit /qunit on your development environment? How about if you run rake plugin:qunit[discouse-humble-box]?

2 curtidas