buster-qunit
An adapter to enable running QUnit tests
from the BusterJS JavaScript testing toolkit.
Installation
Use the npm
package manager to install this package. Assuming
that you are in the same directory where this README file is
located:
% sudo npm install -g .
Usage
You will need to create a buster.js
configuration file for
your qunit tests. The buster.js
file in the examples
folder serves as a template.
To set up a QUnit test suite, the extension has to be selected from
buster.js
:
config["the.example"] = {
rootPath: "../",
environment: "browser",
extensions: [require('buster-qunit')], // select extension
'buster-qunit': {
html: 'examples/test.html' // specify your QUnit test
}
};
All the test and library sources will be mined out of the html you specify
above. You do not need to specify the sources
, tests
or libs
attributes,
as you would normally for a BusterJS test configuration - although if they are
specified, the referred sources will be included in addition to the ones
defined by the HTML.
Roadmap
-
loading resources from QUnit HTML (in progress)
-
add async support (start()
, stop()
, expect(n)
)
Compatibility and restrictions
It is our goal to be able to run any pre-existing QUnit test transparently
from BusterJS, without any need to modify or prepare the QUnit tests.
Right now, in some cases, preparation is necessary to make QUnit tests
compatible with this adapter. Once this is done, the tests can be maintained
as a single source, and run in both QUnit and BusterJS.
1. JavaScript resource loading
QUnit tests are run from a browser by visiting an HTML page, and this HTML
contains <script>
tags to load javascript. In BusterJS, there is no such
HTML. It is the task of buster-qunit
to determine which resources are
requested by the HTML, and marshall their loading to the test configuration.
There are some restrictions which may be elevated in later versions:
-
Only local files with a path relative to this html can be loaded.
Remote loading is currently not supported. Load your resources manually into
a local folder, and use them from there, relatively from the test html
location.
-
Embedded script tags are currently not processed.
-
CSS resources are not loaded. In the unlikely case that your test needed
this, you could use the setup and teardown to load them as needed.
THIS FEATURE IS IN PROGRESS!
2. Async tests not supported
start()
, stop()
and expect(n)
are not implemented. For most cases, you
can use the mock timers and ajax of SinonJS and avoid
the need for async tests.
3. Unsupported HTML problems
There can be cases when the HTML fails in BusterJS while it was working in
QUnit, due to different parsing. If you encounter such a case let us know,
so we can fix and document it.
3.1 SCRIPT tags are filtered out
The SCRIPT tags will be filtered out from the HTML, an if your code makes use
of them, the tests will fail. For example the following will fail:
<script type="text/tmpl" id="joined_left">
<a href="{%= item.profile_url %}">{%= item.author %}</a>
{%= item.operation %}
Community <a href="{%= item.context_url %}">
{%= item.context_name %}
</a>.
</script>
Other example that fails currently:
<script type="text/x-handlebars" data-template-name="application">
{{outlet}}
</script>
This is a problem since various client templating systems use similar markup.
I am looking for a solution to this problem.