I’ve recently started looking at Coffeescript. And to get going with that I’m jumping directly in with unit-testing. I figured that it would be an interesting way to learn the language.
Getting to grips with QUnit
Before we delve into coffeescript part, let’s have a very quick look at QUnit.
In order to run unit tests create an HTML page that will contain the runner. In this page you need to include jQuery, and QUnit (
http://code.jquery.com/qunit/git/qunit.js). The body of your test runner needs to contain elements that QUnit will update during the tests. You also need to include the tests themselves.
I won’t go much further in to QUnit as there is already ample
information about getting going with QUnit over on the jQuery website.
Running coffeescript in the browser
You can run coffeescript in the browser by using the script located at http://jashkenas.github.com/coffee-script/extras/coffee-script.js. Then
any subsequent script blocks that are marked with the
text/coffeescript type will be compiled on-the-fly. e.g.
<script type="text/coffeescript"> // Your coffee script code here </script>
One annoyance I’ve found is that coffeescript relies on “significant whitespace” which means that I’m forced to format my code the way coffeescript likes. In general thats not necessarily a bad thing, especially when you are editing coffeescript files, but with inline script blocks it can be irritating. Your script block may already be indented (and I tend to go for indents of two spaces for HTML files, as opposed to 4 for C#) which coffeescript doesn’t seem to like.
Running some tests
What’s happening above is that the tests run when jQuery is ready. In other words, once the DOM is loaded. (See also:
module method is simply a way of segregating the tests in to groups. All tests that follow a call to
module will be grouped into that “module”.
The test happens in the call to
test which normally takes a string which is the text to display each time the test is run, and a function containing the actual test. The second test that I have is written in coffee script.
<script type="text/coffeescript"> $(()-> module("My coffeescript test"); test("Assert 1 equals 1", ()-> ok(1==1, "One expected to equal one")); ); </script>
While in coffeescript you don’t need the brackets around the function parameters, I prefer them. Nor do you need the semi-colon to terminate each statment, and again this is personal preference. You’ll see lots of coffeescript that won’t use brackets and semi-colons in the above situations.
Here is the result of the two tests above:
In both tests above there is a call to
ok which asserts that the condition passed in as the first argument is true, if not it fails the test. When a test fails the text in the second parameter of the
ok function is displayed. For example, a test designed to deliberately fail:
test("Assert 2 equals 3", () -> ok(2==3, "2 expected to equal 3"));
And the result in the test runner:
Unit testing with .coffee files
Eli Thompson has an example of how you might want to put together unit tests for a
system written in coffeescript. The core of his example is to define a list of coffeescript files and a list of tests and have a bit of coffeescript dynamically load them in order to run the tests.
In that example,
scriptsToTest contains a list of coffeescript files that contain the code to test, and a list of
coffeescript (not including the declaration of the files involved).
This was a very quick introduction to unit testing with QUnit and
using coffeescript. Here are links to more resources to continue