Did you know that Discourse has two large test suites for its code base? On the server side, our Ruby code has a test suite that uses rspec. For the browser application, we have a qunit suite that has ember-testing included.

Assuming you have a development environment set up, if you visit the http://localhost:3000/qunit URL you will start running the Javascript test suite in your browser. One fun aspect is that you can see it testing the application in a miniature window in the bottom right corner:

Adding an Acceptance Test in your Plugin

First, make sure you have the latest version of Discourse checked out. Being able to run Acceptance tests from plugins is a relatively new feature, and if you don’t check out the latest version your tests won’t show up.

For this article I am going to write an acceptance test for the purple-tentacle plugin that we authored in part 5 of this series.

Adding an acceptance test is as easy as adding one file to your plugin. Create the following:

I tried to write the test in a way that is clear, but it might be a little confusing if you’ve never written an acceptance test before. I highly recommend that you read the ember docs on acceptance testing as they have a lot of great information.

The first line of importance is visit("/admin/plugins/purple-tentacle");. This tells our test to navigate to that URL in our application. That URL was the one that displays the tentacle.

The next bit andThen() is a piece of code that will execute after the page has fully loaded. This might be a little confusing if you’ve not done much asynchronous programming before. Browser Applications like Discourse are built using javascript promises. Often, performing an action means that the Javascript application will have to contact the server and wait for a reply.

Visiting a URL almost always involves fetching data from a server, so in Ember all requests are considered asynchronous. That means that we need to write some code that will be called when the routing is finished and ember has loaded the URL. That’s where andThen() comes in.

It almost reads like english doesn’t it? “Visit a URL and THEN perform some tests”.

In this case, I am checking that when the page is initially visited, the #show-tentacle button exists, and that the purple tentacle is hidden. (P.S. the previous version of the purple-tentacle plugin didn’t have the #show-tentacle element id in the handlebars template. Check out the latest version to follow along!)

Once those tests pass it’s time to test the interaction. The next command is click('#show-tentacle'); which tells our testing framework that we want to click the button and show the tentacle.

Finally, we have another andThen function to wait until whatever processing happens when the button is clicked, and then makes sure that the purple tentacle is present.

Not too bad is it? You can try the test yourself by visiting http://localhost:3000/qunit?module=Acceptance%3A%20Purple%20Tentacle on your development machine. You should very quickly see the purtple tentacle appear and all tests will pass.

If you want to run the plugin qunit tests on the command line using PhantomJS, you can run

rake plugin:qunit['purple-tentacle']

(where purple-tentacle is the folder name of your plugin)

Where to go from here

I hate to sound like a broken record but the Ember documentation on testing is excellent. You might also want to see how Discourse tests various functionality by browsing the tests in our javascript tests directory. We have quite a few examples in there you can learn from.

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

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.

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?

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)

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