Entwicklung von Discourse-Plugins – Teil 6: Akzeptanztests hinzufügen

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


Wussten Sie, dass Discourse über zwei große Testsuiten für seine Codebasis verfügt? Auf der Serverseite verfügt unser Ruby-Code über eine Testsuite, die rspec verwendet. Für die Browseranwendung haben wir eine qunit Suite, die ember-testing enthält.

Unter der Annahme, dass Sie eine Entwicklungsumgebung eingerichtet haben, starten Sie beim Aufruf der URL http://localhost:3000/tests die JavaScript-Testsuite in Ihrem Browser. Ein unterhaltsamer Aspekt ist, dass Sie sehen können, wie die Anwendung in einem Miniaturfenster unten rechts getestet wird:

Die Discourse-Anwendung ist mit einer Menge Tests aufgebaut, die beim Aufruf der URL /tests gestartet werden. Daher kann es hilfreich sein, Ihre Tests nach dem Plugin zu filtern, an dem Sie arbeiten. Dies können Sie in der Benutzeroberfläche tun, indem Sie auf das Dropdown-Menü Plugin klicken und Ihr Plugin auswählen:

Hinzufügen eines Akzeptanztests in Ihrem Plugin

Zunächst stellen Sie sicher, dass Sie die neueste Version von Discourse ausgecheckt haben. Die Möglichkeit, Akzeptanztests aus Plugins auszuführen, ist eine relativ neue Funktion. Wenn Sie nicht die neueste Version ausgecheckt haben, werden Ihre Tests nicht angezeigt.

Für diesen Artikel werde ich einen Akzeptanztest für das purple-tentacle Plugin schreiben, das wir in Teil 5 dieser Serie erstellt haben.

Das Hinzufügen eines Akzeptanztests ist so einfach wie das Hinzufügen einer Datei zu Ihrem Plugin. Erstellen Sie Folgendes:

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

Ich habe versucht, den Test so klar wie möglich zu schreiben, aber er könnte verwirrend sein, wenn Sie noch nie einen Akzeptanztest geschrieben haben. Ich dringend empfehle Ihnen, die Ember-Dokumentation zum Thema Akzeptanztests zu lesen, da diese viele großartige Informationen enthält.

In jedem von uns geschriebenen Test müssen wir etwas asserten. In unserem Test möchten wir einige Aussagen treffen, um zu prüfen, ob der Tentakel zunächst ausgeblendet ist und erst nach dem Klicken auf die Schaltfläche angezeigt wird.

Wir möchten eine Reihe von Aktionen definieren, die vor einer Aussage ausgeführt werden sollen. Dazu verwenden wir das Schlüsselwort await. Durch die Verwendung dieses Schlüsselworts warten wir darauf, dass die Ausführung jedes asynchronen Hilfsprogramms abgeschlossen ist.

Unsere erste wichtige Aktion ist: await visit("/admin/plugins/purple-tentacle");. Dies weist unseren Test an, in unserer Anwendung zu dieser URL zu navigieren. Diese URL ist diejenige, die den Tentakel anzeigt.

Nachdem wir die Seite besucht haben, auf der die Schaltfläche für den violetten Tentakel erscheint, möchten wir prüfen, ob wir die Schaltfläche auf der Seite sehen können und ob das Tentakelbild noch nicht vorhanden ist.

Dies wird durch die folgenden Aussagen erreicht:

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

P.S. Die vorherige Version des purple-tentacle-Plugins hatte die Element-ID #show-tentacle nicht in der Handlebars-Vorlage. Schauen Sie sich die neueste Version an, um mitzuhalten!

Sobald diese Tests bestanden sind, ist es an der Zeit, die Interaktion zu testen.

Der nächste Befehl ist await click('#show-tentacle');, der unserem Testframework mitteilt, dass wir auf die Schaltfläche klicken und den Tentakel anzeigen möchten.

Nachdem wir einen Klick auf die Schaltfläche simuliert haben, können wir prüfen, ob der Tentakel erscheint, indem wir folgendes feststellen:

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

Nicht so schlimm, oder? Sie können den Test selbst ausprobieren, indem Sie auf Ihrem Entwicklungsrechner http://localhost:3000/tests?qunit_single_plugin=purple-tentacle&qunit_skip_core=1 aufrufen. Sie sollten sehr schnell sehen, wie der violette Tentakel erscheint und alle Tests bestanden werden.

Wenn Sie die qunit-Tests des Plugins über die Befehlszeile mit PhantomJS ausführen möchten, können Sie Folgendes ausführen:

rake plugin:qunit['purple-tentacle']

(wobei purple-tentacle der Ordnername Ihres Plugins ist)

Debuggen Ihrer Tests

Während Sie Ihre Plugins entwickeln, können Ihnen Ihre Tests helfen, Probleme in Ihrem Plugin zu identifizieren. Wenn Sie Ihre Tests entwickeln oder Änderungen am Code Ihres Plugins vornehmen, können die Tests fehlschlagen. Um zu verstehen, warum, bietet Ember einige nützliche Hilfsprogramme: pauseTest() und resumeTest().

Um sie zu verwenden, fügen Sie await pauseTest() innerhalb Ihres Testcodes an der Stelle ein, an der Sie den Test pausieren möchten. Wenn Sie Ihren Test nun im Browser ausführen, pausiert der Test automatisch an der Stelle, an der Sie pauseTest() hinzugefügt haben. Dies gibt Ihnen die Möglichkeit, die Seite zu inspizieren oder Fehler anzuzeigen, um Probleme zu debuggen.

Wohin es weitergeht

Ich hasse es, wie eine kaputte Schallplatte zu klingen, aber die Ember-Dokumentation zum Testen ist hervorragend. Vielleicht möchten Sie auch sehen, wie Discourse verschiedene Funktionen testet, indem Sie durch die Tests in unserem JavaScript-Testverzeichnis blättern. Wir haben dort einige Beispiele, aus denen Sie lernen können.

Viel Spaß beim Testen!


Mehr in der Serie

Teil 1: Plugin Basics
Teil 2: Plugin Outlets
Teil 3: Site Settings
Teil 4: git setup
Teil 5: Admin interfaces
Teil 6: Dieses Thema
Teil 7: Publish your plugin


Dieses Dokument ist versioniert – schlagen Sie Änderungen auf GitHub vor.

30 „Gefällt mir“

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 „Gefällt mir“

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 „Gefällt mir“

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 „Gefällt mir“

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 „Gefällt mir“

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

1 „Gefällt mir“

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 „Gefällt mir“

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 „Gefällt mir“

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 „Gefällt mir“

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

no,

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 May 13 21:48 ./
drwxr-xr-x 20 tbp tbp 4096 May 13 21:18 ../
drwxr-xr-x  6 tbp tbp 4096 May 13 20:29 discourse-details/
drwxr-xr-x  6 tbp tbp 4096 May 13 21:48 discourse-github-linkback/
drwxr-xr-x  6 tbp tbp 4096 May 13 20:29 discourse-local-dates/
drwxr-xr-x  9 tbp tbp 4096 May 13 20:29 discourse-narrative-bot/
drwxr-xr-x  7 tbp tbp 4096 May 13 20:29 discourse-nginx-performance-report/
drwxr-xr-x  5 tbp tbp 4096 May 13 20:29 discourse-presence/
drwxr-xr-x  3 tbp tbp 4096 May 13 20:29 lazyYT/
drwxr-xr-x  9 tbp tbp 4096 May 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 „Gefällt mir“

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 „Gefällt mir“

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 „Gefällt mir“