Fully namespaced, debuggable unit tests

Colin Clark colin.clark at utoronto.ca
Thu Feb 28 22:41:17 UTC 2008


Hi Anastasia,

Thanks for looking into this. Comments below...

On 28-Feb-08, at 10:29 AM, Anastasia Cheetham wrote:
> 1) The "jQuery.noConflict()" call we use to avoid conflicts with other
> javascript toolkits causes the new testrunner to fail. The testrunner
> relies on the existence of '$', and the noConflict() call eliminates
> that.
>
> I googled this, and the only suggestion was to rewrite testrunner.js
> to avoid using the $ shorthand. Doing so does, indeed, fix the
> problem. I'm not sure of the status of testrunner.js, where Colin got
> it, or whether or not we can feel free to modify it without having to
> deal with merging our changes with external updates to the file.

I have an in-progress patch for testrunner.js that encloses all of its  
code in a closure, using the same technique as is typical for jQuery  
plugins. This approach aliases jQuery to $ in a safe way. Here's a  
simple example:

var myNamespace = function ($) {
   $ ("foo"); // It's safe to use $ in this case because it has been  
defined within function scope, not globally.
} (jQuery);

testrunner.js comes from the jQuery source repository. Here's a link:

http://jqueryjs.googlecode.com/svn/trunk/jquery/test/data/testrunner.js

It's dual-licensed as MIT/GPL, so we're safe to use it and modify it.  
We should, however, share our changes back with the community. I'll do  
so as soon as I've finished the patch. In the meantime, go ahead with  
your temporary workaround.

> 2) The tests are run by simply loading the test HTML file (which
> contains the mark-up that the test work on) in a browser, and the
> results of the tests are 'injected' into a placeholder in the test  
> file.
>
> Implications:
> Currently, our Lightbox 'test file' is also our template, and our
> demonstration file. When I added the necessary changes to the HTML
> file, loading it into the browser did successfully run the tests, but
> then the test results were listed along with the grid of images, which
> is not necessarily what we want if the goal happens to be to
> demonstrate the Lightbox rather than run the tests.
>
> One option is to separate the notion of demonstration file/template
> from test data, and use a separate (albeit almost identical) html file
> for testing purposes. I don't like the idea of identical files lying
> around...

Michelle has been keen to make a split between the Lightbox.html  
template and our unit tests for a number of reasons. One reason for  
this is that we want to distribute a valid template even if the unit  
testing bundle isn't present.

Given that these unit tests are actually Reorderer tests, and need to  
encompass other types of markup aside from the Lightbox, I think it  
makes sense to create this separation. It was highly convenient to  
have everything in one spot, so it's certainly a trade-off.

Identical files aren't at all good, but my point here is that I expect  
that our tests will be better if they work with a variety of types of  
markup rather than assuming a Lightbox structure by default.

What do others think?

Colin

---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org




More information about the fluid-work mailing list