So I've spent what extra time I can in the past two weeks taking a
high-level look at JS unit testing; I've looked at a few systems such as
QUnit, SproutCore/core-test, a few others that have been passed my way
(there's one that Bryan Forbes pointed me at this week that cujo is
apparently adopting but for the life of me I can't remember the name of it
right now, begins with a "b") and comparing that with the current state of
DOH. With that, I'd like to make a proposal to rewrite/refactor DOH into
something that is a top-level independent package. The basics of the
DOH (The Dojo Objective Harness) has served the Dojo Toolkit well since its
inception. It includes all of the assertion code needed for any decent
unit test package, and it does things that many other unit testing
frameworks do not do, such as DOM testing and async-based tests. Creating
actual unit tests is not a difficult thing (though the registration is a
little clunky), and some other things built on top of it (such as
dojox.robot) have been somewhat ground-breaking.
Over the years, a number of dependencies on aspects of the Dojo Toolkit
have crept into the framework, such as performance analysis using Charting
(optional, currently only required if a specific "has" test is present) and
a hard dependency on dojox.testing, which has not been touched since
Wolfram added it (as far as I can tell). This particular dependency is an
attempt to emulate Python-esque "doctests", where tests can be embedded as
comments and parsed out as run.
In addition, the original interface is still in play--no updates have been
made to it since Alex originally wrote it (with his playful addition of the
Homer Simpson "doh!" to alert someone to test failures)...and the way HTML
tests are set up rely on a strict path-based HTML bootstrap (i.e.
What has changed since DOH's original conception:
The primary change has been the invention and introduction of AMD, and the
ability (though not really germane here) of dojo.declare to define
anonymous objects (i.e. it returns a constructor function as opposed to
defining it based on a string).
Issues with DOH:
After analyzing (again, at a high level) DOH, it seems that there are
problems that need to be addressed:
1) The creeping in of DTK dependencies, though done with something of a
2) The way DOH has *everything* attached to a single object (i.e.
everything is "doh.foo")
3) Related to both 1 and 2: the lack of separation of concerns. In other
words, assertions == runners == interface.
DOH 2.0 - or "how I learned to love the unit test":
(insert Kubrick reference here ;))
What I propose is the following--
1) Assertions and base runners need to be refactored into library-agnostic
anonymous AMD modules. This will be the foundation for the testing suite,
and will probably need to include some versions of Promises and/or a highly
simplified version of dojo/on.
2) An HTML application should be written that consumes the assertion and
runner modules. This application should be written in such a way as to
both demonstrate how to write an application to consume the assertion and
runner modules, as well as promote teh sexy? that we all know DTK is
With regards to the first point, there can be NO dependencies other than an
AMD-compliant loading mechanism. In the end, someone should be able to
take the assertion and runner modules and use them for their own purposes
with RequireJS or any other AMD loader.
On the second point...dependency away on the Dojo Toolkit! Performance
metrics with charting, manipulating the interface using dojo/query et al,
more than fine!
Of course, when talking about a rewrite/refactor, the immediate question
comes to mind--why not just use something else that is out there? And it
is a good question. My main reasoning against it is that I have yet to see
a JS Unit Testing platform that integrates promises and AMD well--and
inevitably whatever "application" is consuming the runner is biased towards
whatever it is primarily aimed at testing. I don't see DTK as an exception
to that tendency.
What we gain:
1) A superior yet simple unit testing framework that is a stand-alone
2) An application to consume that unit testing framework that can be used
as a marketing tool and as a demo application.
3) Something that does not rely on specialized servers, and/or a reliance
on a particular language other than HTML/CSS/JS (some of the unit testing
frameworks out there require things like PHP, Java, Node or Python
installations as an example).
This is more of a high-level proposal than anything else, and feedback is
more than welcome on all fronts. Obviously I have not addressed DOH robot
or something such as TestSwarm, but I do think that starting small is
better than anything. In the very least, the current HTML runner needs a
lot of love--particularly in light of the idea that we are moving to
packages. Better to have a single package that can be grabbed quickly and
run any number of tests than to sprinkle packages with things like
runTests.html with a meta redirect.
Thanks for your time--
-------------- next part --------------
An HTML attachment was scrubbed...
An HTML attachment was scrubbed...