Développement de plugins Discourse - Partie 6 - Ajouter des tests d'acceptation

Tutoriel précédent : Developing Discourse Plugins - Part 5 - Add an admin interface


Saviez-vous que Discourse possède deux grandes suites de tests pour sa base de code ? Du côté serveur, notre code Ruby dispose d’une suite de tests qui utilise rspec. Pour l’application navigateur, nous avons une suite qunit qui inclut ember-testing.

En supposant que vous ayez configuré un environnement de développement, si vous visitez l’URL http://localhost:4200/tests, vous commencerez à exécuter la suite de tests JavaScript dans votre navigateur. Un aspect amusant est que vous pouvez la voir tester l’application dans une fenêtre miniature dans le coin inférieur droit :

L’application Discourse est construite avec beaucoup de tests qui commenceront à s’exécuter lorsque vous visiterez l’URL /tests. Il peut donc être utile de filtrer vos tests par le plugin sur lequel vous travaillez. Vous pouvez le faire dans l’interface en cliquant sur le menu déroulant Plugin et en sélectionnant votre plugin :

Ajout d’un test d’acceptation dans votre plugin

Tout d’abord, assurez-vous d’avoir la dernière version de Discourse extraite. La possibilité d’exécuter des tests d’acceptation à partir de plugins est une fonctionnalité relativement nouvelle, et si vous n’avez pas extrait la dernière version, vos tests n’apparaîtront pas.

Pour cet article, je vais écrire un test d’acceptation pour le plugin purple-tentacle que nous avons créé dans la partie 5 de cette série.

Ajouter un test d’acceptation est aussi simple que d’ajouter un fichier à votre plugin. Créez ce qui suit :

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!");
  });
});

J’ai essayé d’écrire le test d’une manière claire, mais il pourrait être un peu déroutant si vous n’avez jamais écrit de test d’acceptation auparavant. Je vous recommande vivement de lire la documentation d’Ember sur les tests d’acceptation car elle contient beaucoup d’informations utiles.

Dans chaque test que nous écrivons, nous devons assert (affirmer) quelque chose. Dans notre test, nous voulons faire quelques assertions pour vérifier si la tentacule est masquée initialement, puis affichée uniquement après avoir cliqué sur le bouton.

Nous voulons définir un ensemble d’actions à entreprendre avant qu’une assertion ne soit faite. Pour ce faire, nous utilisons le mot-clé await. En utilisant ce mot-clé, nous attendons d’abord que l’exécution de chaque aide asynchrone soit terminée.

Notre première action importante est : await visit("/admin/plugins/purple-tentacle");. Cela indique à notre test de naviguer vers cette URL dans notre application. Cette URL était celle qui affichait le bouton de la tentacule violette.

Après avoir visité la page où le bouton de la tentacule violette apparaît, nous voulons vérifier si nous pouvons voir que le bouton sur la page existe et que l’image de la tentacule n’existe pas encore.

Ceci est réalisé par les assertions suivantes :

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

P.S. la version précédente du plugin purple-tentacle n’avait pas l’ID d’élément #show-tentacle dans le template handlebars. Consultez la dernière version pour suivre !

Une fois que ces tests réussissent, il est temps de tester l’interaction.

La commande suivante est await click('#show-tentacle'); qui indique à notre framework de test que nous voulons cliquer sur le bouton et afficher la tentacule.

Après avoir simulé un clic sur le bouton, nous pouvons vérifier si la tentacule apparaît en affirmant :

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

Pas trop mal, n’est-ce pas ? Vous pouvez essayer le test vous-même en visitant http://localhost:4200/tests?qunit_single_plugin=purple-tentacle&qunit_skip_core=1 sur votre machine de développement. Vous devriez très rapidement voir la tentacule violette apparaître et tous les tests réussiront.

Si vous souhaitez exécuter les tests qunit du plugin en ligne de commande en utilisant PhantomJS, vous pouvez exécuter

rake plugin:qunit['purple-tentacle']

(où purple-tentacle est le nom du dossier de votre plugin)

Débogage de vos tests

Lorsque vous écrivez vos plugins, vos tests peuvent vous aider à identifier les problèmes dans votre plugin. Lorsque vous développez vos tests ou que vous apportez des modifications au code de votre plugin, les tests peuvent échouer. Pour vous aider à comprendre pourquoi, Ember dispose de quelques aides utiles : pauseTest() et resumeTest().

Pour les utiliser, ajoutez await pauseTest() dans votre code de test là où vous souhaitez que le test s’arrête. Maintenant, lorsque vous exécutez votre test dans le navigateur, le test s’arrêtera automatiquement au point où vous avez ajouté pauseTest(). Cela vous donnera une chance d’inspecter la page ou de visualiser les erreurs pour vous aider à déboguer les problèmes.

Par où commencer ensuite

Je déteste sonner comme un disque rayé, mais la documentation d’Ember sur les tests est excellente. Vous voudrez peut-être également voir comment Discourse teste diverses fonctionnalités en parcourant les tests dans notre répertoire de tests JavaScript. Nous avons pas mal d’exemples là-dedans à partir desquels vous pouvez apprendre.

Bonne chance pour les tests !


Plus dans la série

Partie 1 : Bases des plugins
Partie 2 : Sorties de plugins
Partie 3 : Paramètres du site
Partie 4 : Configuration git
Partie 5 : Interfaces d’administration
Partie 6 : Ce sujet
Partie 7 : Publiez votre plugin


Ce document est contrôlé par version - suggérez des modifications sur github.

30 « J'aime »

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 « J'aime »

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 « J'aime »

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 « J'aime »

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 « J'aime »

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

1 « J'aime »

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 « J'aime »

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 « J'aime »

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 « J'aime »

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 « J'aime »

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 « J'aime »

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 « J'aime »