Running asynchronous QUnit tests from Ant in PhantomJS

Question

I am attempting to get a set of asynchronous QUnit tests to run from an Ant build script, using PhantomJS. What I have seems to be working, but it seems like there should be a nicer way to achieve it.

The script (simplified) that runs when PhantomJS loads is as follows:

var page = require("webpage").create();

page.onConsoleMessage = function(msg) {
    if(msg.indexOf("FINISHED") > -1) {
        var failed = msg.split(" ");
        phantom.exit(failed[1]);
    }
};

page.open("testrunner.html", function() {
    page.evaluate(function() {
        QUnit.done = function(result) {
            console.log("FINISHED " + result.failed);
        };
    });
});

This loads the file which contains the tests (testrunner.html). It uses the PhantomJS evaluate method to run some code in the context of the loaded page. That code binds an event handler to the QUnit done event. In the event handler, all that happens is a simple call to console.log.

PhantomJS does not do anything with console.log calls by default, so I have also bound an event handler to the PhantomJS onConsoleMessage event. When the console.log call in the QUnit.done event handler is executed, the onConsoleMessage event is triggered. If the console message matches a given string, then we know the tests have finished running. We can then exit PhantomJS, with an exit code equal to the number of failed unit tests (this is used by the Ant script to determine whether or not this part of the build was successful).

My question is, is there a better way to find out when the unit tests have finished running?

Claussen

Answer 1

Have you checked out the qunit runner that is provided on the phantom js webiste? https://github.com/ariya/phantomjs/blob/1.2/examples/run-qunit.js

Essentially you just point it to your qunit test page (testrunner.html) and it scrapes the page to see if anything has failed and outputs the results to the console. You could modify it to print to a file which can then be integrated into your build script.

Schnitzler

Thanks, I hadn't seen that yet. However, it looks very much like what I'm already doing, just switching the onConsoleMessage callback for a setTimeout loop that waits for some condition to be true, or for a set amount of time to pass. I'm really looking to avoid things like that (1 concern for example - what if for some reason the request took longer than the maximum allowed time?) That's why I've gone with the onConsoleMessage event approach I'm using at the moment. – Claussen

I agree, your method is more concise since you have the advantage of knowing when your tests are complete (given the QUNIT.done callback). I can see the waitFor method being useful for the case when you do not, like when you are waiting for an element on the page to be visible. I'm actually doing something very similar to what you're doing, except instead of pointing to a qunit test page I'm pointing to pages on my site, injecting my qunit tests right in the page so I can do integration testing on the html/js. – Schnitzler