HTML and CSS Reference
In-Depth Information
3.1.6 Dependencies
Ideally, a testing framework should have as few dependencies as possible. More
dependencies increase the chance of the mechanics of the framework not working
in some browser (typically older ones). The worst kind of dependency for a testing
framework is an obtrusive library that tampers with the global scope. The original
version of JsUnitTest, the testing framework built for and used by the Prototype.js
library, depended on Prototype.js itself, which not only adds a number of global
properties but also augments a host of global constructors and objects. In practice,
using it to test code that was not developed with Prototype.js would prove a futile
exercise for two reasons:
•
Too easy to accidentally rely on Prototype.js through the testing framework
(yielding green tests for code that would fail in production, where
Prototype.js would not be available)
•
Too high a risk for collisions in the global scope (e.g., the MooTools library
adds many of the same global properties)
The original JavaScript port of the JUnit framework was JsUnit, first released in
2001. Not surprisingly, it has in many ways set the standard for a lot of testing
frameworks following it. JsUnit runs tests in a browser: The test runner prompts
for the URL to a test file to execute. The test file may be an HTML test suite which
links to several test cases to execute. The tests are then run in sandboxed frames,
and a green progress bar is displayed while tests are running. Obviously, the bar
turns red whenever a test fails. JsUnit still sees the occasional update, but it has not
been significantly updated for a long time, and it's starting to lag behind. JsUnit
has served many developers well, including myself, but there are more mature and
up-to-date alternatives available today.
Common for the in-browser testing frameworks is how they require an HTML
fixture file to load the files to test, the testing library (usually a JavaScript and a CSS
file), as well as the tests to run. Usually, the fixture can be simply copy-pasted for
each new test case. The HTML fixture also serves the purpose of hosting dummy
markup needed for the unit tests. If tests don't require such markup, we can lessen
the burden of keeping a separate HTML file for each test case by writing a script
that scans the URL for parameters naming library and test files to load, and then
load them dynamically. This way we can run several test cases from the same HTML
fixture simply by modifying the URL query string. The fixture could of course also
be generated by a server-side application, but be careful down this route. I advise you
