Skip to main content

unittest TestSuite integrating a QUnit javascript suite into a unittest flow

Project description

QUnitSuite is a unittest.TestSuite able to run QUnit test suites within the normal unittest process, through PhantomJS.

QUnitSuite is built upon Ben Alman’s work of for the interfacing between PhantomJS and the host/reporting code: the shims and the PhantomJS configuration files are those of grunt’s qunit task.


You’re a Python shop or developer, you have tools and tests built around unittest (or compatible with unittests) and your testing pipeline is predicated upon that, you’re doing web development of some sort these days (as so many are) and you’d like to do some testing of your web stuff.

But you don’t really want to redo your whole testing stack just for that.

QUnitSuite simply grafts QUnit-based tests, run in PhantomJS, in your existing unittest-based architecture.


QUnitSuite currently provides a single object as part of its API: qunitsuite.QUnitSuite(testfile[, timeout]).

This produces a unittest.TestSuite suitable for all the usual stuff (running it, and giving it to an other test suite which will run it, that is).

testfile is the HTML file bootstrapping your qunit tests, as would usually be accessed via a browser. It can be either a local (file:) url, or an HTTP one. As long as a regular browser can open and execute it, PhantomJS will manage.

timeout is a check passed to the PhantomJS runner: if the runner produces no information for longer than timeout milliseconds, the run will be cancelled and a test error will be generated. This situation usually means either your testfile is not a qunit test file, qunit is not running or qunit’s runner was stopped (for an async test) and never restarted.

The default value is very conservative, most tests should run correctly with lower timeouts (especially if all tests are synchronous).


unittest’s autodiscovery protocol does not directly work with test suites (it looks for test cases). If you want autodiscovery to work correctly, you will have to use the load_tests protocol:

# in a testing module
def load_tests(loader, tests, pattern):
    return tests

outside of that specific case, you can use a QUnitSuite as a standard TestSuite instance, running it, adding it to an other suite or passing it to a TestRunner

Complaints and Grievances


Starting up a phantomjs instance and running a suite turns out to have a rather high overhead, on the order of a second on this machine (2.4GHz, 8GB RAM and an SSD).

As each QUnitSuite currently creates its own phantomjs instance, it’s probably a good idea to create bigger suites (put many modules & tests in the same QUnit html file, which doesn’t preclude splitting them across multiple js files).


QUnitSuite contains a pretty big hack which may or may not cause problem depending on your exact setup: in case of case failure or error, unittest.TestResult formats the error traceback provided alongside the test object. This goes through Python’s traceback-formatting code and there are no hooks there.

One could expect to use a custom TestResult, but for test suites the TestResult instance must be provided by the caller, so there is no direct hook onto it.

This leaves three options:

  • Create a custom TestResult class and require that it be the one provided to the test suite. This requires altered work flows, customization of the test runner and (as far as I know) isn’t available through Python 2.7’s autodiscovery. It’s the cleanest option but completely fails on practicality.
  • Create a custom TestResult which directly alters the original result’s errors and failures attributes as they’re part of the testrunner API. This would work but may put custom results in a strange state and break e.g. unittest2’s @failfast.
  • Lastly, monkeypatch the undocumented and implementation detail _exc_info_to_string on the provided result. This is the route taken, at least for now.

Project details

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Files for QUnitSuite, version 0.3
Filename, size File type Python version Upload date Hashes
Filename, size QUnitSuite-0.3.tar.gz (23.3 kB) File type Source Python version None Upload date Hashes View

Supported by

AWS AWS Cloud computing Datadog Datadog Monitoring Facebook / Instagram Facebook / Instagram PSF Sponsor Fastly Fastly CDN Google Google Object Storage and Download Analytics Huawei Huawei PSF Sponsor Microsoft Microsoft PSF Sponsor Pingdom Pingdom Monitoring Salesforce Salesforce PSF Sponsor Sentry Sentry Error logging StatusPage StatusPage Status page