A friend of mine recently sent me a link to John Resig’s blog entry on a new JavaScript unit testing extension/framework called FireUnit. After reading it, I was very excited to see something like this available, because unit testing JavaScript inside an add-on has not typically been a fun experience for me. I played with the extension this past weekend, and this entry documents my thoughts. (You should definitely read John’s post first if you are not familiar with FireUnit.)
The first step is obviously to download the extension, available at http://fireunit.org. I put a "Hello World"-type test together just to see the results. It should be no surprise that I saw the results in Firebug’s new Test panel when I opened the HTML page in Firefox.
<script>
fireunit.ok("Hello World", "’Hello World’ is truthy!");
</script>
So far so good. I noticed that FireUnit supported running tests from multiple HTML files, so I tried that based on what I found on the FireUnit examples wiki page.
<script>
if (fireunit.forceHttp()) {
fireunit.runTests("1.html", "2.html");
}
</script>
I was a bit disappointed to see the following chrome error in Firebug when I ran this page:
What I should’ve done immediately was to download the source, but I was already sucked into hacking my local version to get it to work. I eventually did download the FireUnit source, but I still received errors like "nsHttpServer is not defined." (I tried to discover the cause of this problem, but after a couple hours of tweaking the httpd.js file, I decided to cut my losses and try something else.)
Not to be deterred (mainly because I really like the idea of FireUnit), I set out on writing an alternative to running test suites. What I created wasn’t pretty, but it was functional. I overwrote the fireunit.runTests function to take each argument and make a synchronous XMLHttpRequest for that specific page. Once I received the page, I would import all of the scripts on that page (i.e. importing the scripts in all of the script elements that had a src attribute). After all the scripts were imported, I would eval() the remaining inline scripts on the page which contained the tests themselves. Finally, I would repeat the process for the next test file, until all tests in all test files had run. It took a while to get this just right, but now I’m happy building tests instead of test infrastructure.
Another way I’m being unorthodox with FireUnit is that my tests are actually HTML files embedded in the add-on itself. This offers a few advantages over using a local HTML page but also comes with its own set of disadvantages. The main advantage is that I don’t have to deal with enabling the UniversalXPConnect privilege in every test function or (more importantly) the code I’m testing. The main disadvantage is that Firebug will not show the source for script files that exist in chrome (probably with good reason); perhaps this is just a Firebug preference that I’m missing.
Thoughts on FireUnit? I like what the extension aims to do and what it allows me to do already, albeit with some heavy tweaking. I know it’s in its early stages, but I can’t imagine that everyone would be willing to spend as much time as I did to set up the environment. On the other hand, it’s possible that not everyone will run into the same issues I did, especially with the nsHttpServer. I can’t think of much to improve besides making it much easier to run tests from multiple HTML files. About the only thing I would enjoy it would be great to see a QUnit-like HTML report for tests, with each module being a separate HTML file.
Now back to testing…
Posted by David DeWinter under Firefox & JavaScript | No Comments »
Syndication