I’ve also been bitten by the QUnit bug so before I enable CoffeeScript on Cheezburger.com, I want to make sure that I can unit test whatever CoffeeScript we write. A quick Google search yielded next to nothing about testing CoffeeScript but I was feeling inventive and came up with the following way to use QUnit with CoffeeScript.
Since we’re going to load .coffee scripts via jQuery.get(), they must be served by a web server. They will not load off the local file system if you simply open index.htm locally. If anyone finds a way around this, feel free to comment on the gist.
I enabled IIS Express to serve .coffee files by adding the following element to applicationhost.config in the configuration/system.webserver/staticContent element:
<mimeMap fileExtension=”.coffee” mimeType=”text/plain” />
Here is a contrived Dog class and a test for it:
And here’s the index.htm which runs the tests:
I started out with the normal set of QUnit files (index.htm, the css, and js), then included the coffee-script.js which enables us to execute CoffeeScript written in a <script type=”text/coffeescript”></script> tag. My usage of this tag in the code was completely unnecessary, but I thought this example would be more interesting if it was ALL CoffeeScript.
The scriptsToTest variable is a list of paths to .coffee files which will get loaded on the page. The tests variable is similar, but holds the tests. I split these up simply for readability.
The loadCoffee function spins through the contents of each of the files handed to it, executes the CoffeeScript compiler on them, and injects a script tag containing the compiled code into the page.
It’s important to include the “bare: on” option when calling the CoffeeScript.compile function. If bare is off (false), then the compiled code will be wrapped in a function so that declared variables get declared globally. My tests expect the Dog class to be declared globally, so I set bare to on.
Here’s a zip file full of all the files to make this example run (except for IIS Express):