Beginner’s Guide to Creating Discourse Plugins Part 6: Acceptance Tests


tbp@tbp-linux-dev:~$ cd ~/discourse/plugins/
git clone -b allow-all-user-repositories-wildcard
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/

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 Like

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:)


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:

Travis.CI Result - Travis CI - Test and Deploy Your Code with Confidence
Test-File -

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]?

LOAD_PLUGINS=1 QUNIT_SKIP_CORE=1 QUNIT_SINGLE_PLUGIN='discouse-humble-box' /home/ravenstorm/.rbenv/versions/2.5.3/bin/rake qunit:test
Chrome is not installed. Download from
rake aborted!
Command failed with status (1): [LOAD_PLUGINS=1 QUNIT_SKIP_CORE=1 QUNIT_SIN...]
/home/ravenstorm/discourse/lib/tasks/plugin.rake:117:in `block in <main>'
Tasks: TOP => plugin:qunit
1 Like

Install Chrome and then give it another try.

1 Like

Oh sorry i’ve pasted an old error code which i had stored in a pastebin :frowning_face:

navigate to http://localhost:60099/qunit?qunit_single_plugin=discouse-humble-box&qunit_skip_core=1&seed=187998423095278311109560784485973475676
Tests timed out
rake aborted!
Command failed with status (124): [node /home/ravenstorm/discourse/vendor/ass...]
/home/ravenstorm/discourse/lib/tasks/qunit.rake:89:in `block in <main>'
Tasks: TOP => qunit:test
(See full trace by running task with --trace)
rake aborted!
Command failed with status (1): [LOAD_PLUGINS=1 QUNIT_SKIP_CORE=1 QUNIT_SIN...]
/home/ravenstorm/discourse/lib/tasks/plugin.rake:117:in `block in <main>'
Tasks: TOP => plugin:qunit

Try running the test in the browser as David suggested earlier. So, in your browser, when the server is running, go to your-local-site/qunit. Very often, for me, timeouts in the Terminal have errors in JS that I could see and fix after visiting /qunit on the browser.

Thats one of the problems :smiley:

I can’t find acceptance tests on my /qunit

Even after turning on all modules and filtering it with box and humble nothing is here :slightly_frowning_face:

Try renaming the folder to test/javascripts/acceptance - that extra s is quite important!

You might need to do rm -rf tmp, and then restart your development server for the changes to take effect.

1 Like

Do what David said above (rename the folder to javascripts), but ALSO, change the name of your plugin in plugin.rb to discourse-humble-box to match the folder name. I did these two changes, and I see tests locally:


Yea i’ve seen those as well now, but these aren’t really eye-opening results tbh.

But gotta dig deeper and lookup why these errors are shown.

Thanks for the help guys.
For example the second test case… if i am testing it myself by hand… it works, but running it on qunit it fails :frowning:

Ok, got a brief idea whats bringing me the errors and it confuses me:
http://localhost:9292/ in my browser has the plugin installed and working
http://localhost:9292/qunit the test shows, that the plugin is not even installed

I thought these two are using the same enviroment ?
Could this be caused by my local dev-enviroment since it’s not using docker and I’m not able to install the plugin like Install Plugins in Discourse ? It’s just sitting in the plugins folder like the others.

Any idea how this is possible ?

I’m trying to follow this guide, but I’m getting stuck right at the beginning: I can’t access /qunit at all. (This also seems related to the Beginners Guide to Install Discourse on Ubuntu for Development, which is basically the approach I’m using to deploying Discourse on my local machine for learning about development, but this guide is the prompt that triggered my obstacle, so I thought I’d put it here.) Attempting to access it gives a “That page doesn’t exist or is private” response.

The controller for the /qunit route (discourse/qunit_controller.rb at 166fe3bb34f99bd0baa613726486ce0f13c7a992 · discourse/discourse · GitHub) mentions that it is # only used in non-ember-cli test / dev (the comment before that method), so I’ve tried running the instance with RAILS_ENV=test bundle exec rails server, but EmberCli.enabled? is still true.

What approach are you all using to run a local development server such that we can actually access /qunit (which probably involves disabling EmberCLI)? (I certainly may be missing something obvious.)

1 Like

The new path is /tests. I’ll update the OP - thanks!


Great, thanks! On to the next obstacle:

This direct link to the particular acceptance test gives the error (with a backtrace):

Error: No tests matched the module "Acceptance: Purple Tentacle".

Indeed, when I search through the “Module:” select list, I don’t see anything there matching “purple” or “Purple”. Is there a new piece to the system for registering plugins or their tests that may be missing here?

If I search for “purple” using the “Filter:” text box, it takes me to the following URL: http://localhost:4200/tests?filter=purple, which gives me a different error:

Error: Could not find module `helpers/qunit-helpers` imported from `discourse/plugins//acceptance/purple-tentacle-test`
    at missingModule (http://localhost:4200/assets/vendor.js:259:11)

Do you have any ideas for what might be out of place here?

As a sidebar, does the /tests URL use the catch-all get "*url", to: 'permalinks#show' route, and thus Permalink.find_by_url to actually resolve? If so, at what point in Discourse initialization does the /tests URL mapping get loaded into the database?

@jlc, thank you so much for trying out our guide and keeping us up to date. :meow_heart:

I’ve made some changes to the OP’s example acceptance test to reflect some new changes we’re using for acceptance tests. Essentially, the two changes are

  • imports, and
  • the usage of the needs constant within acceptance

That should solve most of the issues you’ve mentioned. You can also make use of some of the needs options here:

Looking through the whole qunit-helpers file would also be very useful!

1 Like