Getting A Test Project Set Up
Christopher Bennage has already blogged about the basic set up that we put in to our project. The gist of it is that we have to manually add a linked file from our production app in to our test runner app, every time we need to write tests for that production file. We’ve also had to manually add the individual file reference as a <script> tag, along with a <script> tag for the tests for that file, in side of our “default.html” file. This tells the project to load and run the script and its associated tests.
The result of all this manual <script> tag maintenance was painful at best, and nightmarish most of the time. Here’s an incomplete screenshot of all the files that we had to manually add as <script> tags. Note that I said incomplete screenshot…
Reducing The Script Tag Nightmare
I got tired of this, as you can imagine, so I fixed it. Yesterday I introduced a bit of code that allowed me to reduce the number of <script> tags from what you see in the screenshot above, down to this:
That’s much better! And the best part is, I don’t have to touch this file again. I can add specs to my app, and link production files in to the test runner all day long, and I never need to change this file.
The key to the reduction of <script> tags is that last file I included: specRunner.js. This file takes advantage of the WinRT/WinJS runtime environment to examine the local file system that the code is running from, use a few very simple conventions along with a bit of configuration to find the files it needs, and dynamically generate the needed <script> tags for me, inserting them in to the DOM.
Configuring The SpecRunner
In the “default.js” page control, I have this code:
Here you can see the few bits of configuration that I’m passing in – the folder that contains the source files, the spec files, and a helpers folder. This helpers folder is used to load up any helper scripts – extra libraries, common functions, and anything else you need that isn’t directly a test. Just drop a .js file in this folder and it will be included in the test runner.
I’ve also included an “error” event that gets dispatched from the spec runner object, as you can see. This uses the eventMixin that I’ve blogged about before to dispatch events. The purpose of this trigger is to let you know when the test runner configuration has failed. It does not report errors from Mocha or Jasmine or anything like that, only from the spec runner set up.
Coding The SpecRunner
My implementation of the spec runner is fairly simple, but it does do quite a bit. The heavy use of WinJS promises necessitates a lot of callback functions which I like to organize in to a series of steps to perform.
You can the high level list of steps in the “run” method, with each of those primary steps being a breakdown of other steps to takes. I’ve also hard coded my version of the spec runner to configure and run Mocha tests. It would not be difficult to change this to run Jasmine tests, or to abstract this a little bit more and make the test runner configurable with callback functions or other means.
Follow The Code; We’re Not Done Yet
I love this solution. It was easy to write and it works very well for our project. But we’re not done solving the unit testing problem, yet. I still have to manually link the files from the production app in to the test app. We’re thinking through solutions to that problem as well, but it’s proving to be much more difficult than we had hoped.
Also, if you’re interested in following along as we make project through this project (through the end of September, basically), you can get the code from our CodePlex repository. Be sure to check out the discussion list as well. There’s a lot of great discussion going on, and some very interesting insights in to the thought process of our project structure and architecture.