Sviluppo di plugin per Discourse - Parte 6 - Aggiunta di test di accettazione

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


Sapevate che Discourse dispone di due grandi suite di test per il proprio codice? Sul lato server, il nostro codice Ruby ha una suite di test che utilizza rspec. Per l’applicazione browser, abbiamo una suite qunit che include ember-testing.

Supponendo che abbiate configurato un ambiente di sviluppo, se visitate l’URL http://localhost:3000/tests inizierete a eseguire la suite di test JavaScript nel vostro browser. Un aspetto divertente è che potete vederla testare l’applicazione in una finestra in miniatura nell’angolo in basso a destra:

L’applicazione Discourse è costruita con un sacco di test che iniziano a essere eseguiti quando visitate l’URL /tests. Quindi potrebbe essere utile filtrare i test in base al plugin su cui state lavorando. Potete farlo nell’interfaccia cliccando sul menu a tendina Plugin e selezionando il vostro plugin:

Aggiungere un test di accettazione nel vostro plugin

Per prima cosa, assicuratevi di aver scaricato l’ultima versione di Discourse. La possibilità di eseguire test di accettazione dai plugin è una funzionalità relativamente nuova; se non scaricate l’ultima versione, i vostri test non appariranno.

In questo articolo scriverò un test di accettazione per il plugin purple-tentacle che abbiamo creato nella parte 5 di questa serie.

Aggiungere un test di accettazione è semplice come aggiungere un file al vostro plugin. Create il seguente:

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("Il pulsante Purple tentacle funziona", async function (assert) {
    await visit("/admin/plugins/purple-tentacle");
    assert.ok(exists("#show-tentacle"), "mostra il pulsante Purple tentacle");
    assert.ok(!exists(".tentacle"), "il tentacolo non è ancora mostrato");
    await click("#show-tentacle");
    assert.ok(exists(".tentacle"), "il tentacolo vuole dominare il mondo!");
  });
});

Ho cercato di scrivere il test in modo chiaro, ma potrebbe risultare un po’ confuso se non avete mai scritto un test di accettazione prima. Consiglio vivamente di leggere la documentazione di Ember sui test di accettazione, poiché contiene molte informazioni utili.

In ogni test che scriviamo, dobbiamo assertare qualcosa. Nel nostro test, vogliamo fare alcune asserzioni per verificare se il tentacolo è inizialmente nascosto e poi mostrato solo dopo aver cliccato sul pulsante.

Vogliamo definire un insieme di azioni da compiere prima di effettuare un’asserzione. Per farlo, usiamo la parola chiave await. Utilizzando questa parola chiave, attendiamo che l’esecuzione di ogni helper asincrono sia completata prima di procedere.

La nostra prima azione importante è: await visit("/admin/plugins/purple-tentacle");. Questo dice al nostro test di navigare verso quell’URL nella nostra applicazione. Quell’URL è quello che visualizza il tentacolo.

Dopo aver visitato la pagina in cui appare il pulsante Purple tentacle, vogliamo verificare se possiamo vedere il pulsante sulla pagina e se l’immagine del tentacolo non esiste ancora.

Questo viene fatto dalle seguenti asserzioni:

assert.ok(exists("#show-tentacle"), "mostra il pulsante Purple tentacle");
assert.ok(!exists(".tentacle"), "il tentacolo non è ancora mostrato");

P.S. La versione precedente del plugin purple-tentacle non aveva l’ID elemento #show-tentacle nel template Handlebars. Consultate l’ultima versione per seguire il tutorial!

Una volta che questi test passano, è il momento di testare l’interazione.

Il prossimo comando è await click('#show-tentacle'); che dice al nostro framework di test che vogliamo cliccare il pulsante e mostrare il tentacolo.

Dopo aver simulato un clic sul pulsante, possiamo verificare se il tentacolo appare eseguendo l’asserzione:

assert.ok(exists(".tentacle"), "il tentacolo vuole dominare il mondo!");

Non è male, vero? Potete provare il test voi stessi visitando http://localhost:3000/tests?qunit_single_plugin=purple-tentacle&qunit_skip_core=1 sulla vostra macchina di sviluppo. Dovreste vedere molto rapidamente apparire il tentacolo viola e tutti i test passeranno.

Se volete eseguire i test qunit del plugin da riga di comando utilizzando PhantomJS, potete eseguire

rake plugin:qunit['purple-tentacle']

(dove purple-tentacle è il nome della cartella del vostro plugin)

Debug dei vostri test

Mentre scrivete i vostri plugin, i vostri test possono aiutarvi a identificare problemi nel plugin. Quando state sviluppando i vostri test o se apportate modifiche al codice del plugin, i test potrebbero fallire. Per capire il motivo, Ember offre alcuni utili helper: pauseTest() e resumeTest().

Per utilizzarli, aggiungete await pauseTest() all’interno del codice del test nel punto in cui desiderate che il test si interrompa. Ora, quando eseguite il test nel browser, il test si fermerà automaticamente nel punto in cui avete aggiunto pauseTest(). Questo vi darà la possibilità di ispezionare la pagina o visualizzare eventuali errori per aiutare a risolvere i problemi.

Da dove andare avanti

Odio sembrare un disco rotto, ma la documentazione di Ember sui test è eccellente. Potreste anche voler vedere come Discourse testa varie funzionalità esplorando i test nella nostra directory dei test JavaScript. Abbiamo diversi esempi lì dentro da cui potete imparare.

Buoni test!


Altri articoli della serie

Parte 1: Nozioni di base sui plugin
Parte 2: Plugin Outlets
Parte 3: Impostazioni del sito
Parte 4: Configurazione git
Parte 5: Interfacce di amministrazione
Parte 6: Questo argomento
Parte 7: Pubblicate il vostro plugin


Questo documento è sotto controllo versione: suggerite modifiche su GitHub.

30 Mi Piace

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 Mi Piace

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 Mi Piace

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 Mi Piace

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 Mi Piace

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

1 Mi Piace

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 Mi Piace

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 Mi Piace

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 Mi Piace

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? - #6 by tgxworld

1 Mi Piace

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 Mi Piace

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 · GitHub

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 Mi Piace