I strongly believe in unit testing and recently I spent a bit of time trying to apply this technique to Java Script code.
The first problem that I had to solve was which framework to use. From what I’ve read it looks like
JSSpec,
qUnit and
YUI Test get most of the attention nowadays. YUI is the most mature from them and offers by far the most functionality out of the box. On the other hand it is the most complex one to setup but still the whole process takes only a few copy/paste clicks. At the end of the day I decided to go with YUI Test because I wanted to check if I really need its rich capabilities.
In C# world to make unit testing easy we use mocking frameworks. In Java Script world mocking frameworks are not needed because Java Script is a dynamic language and every method/object can be overwritten at any time at runtime. Still mocking might take a bit of effort because you have to keep the original method somewhere around to put it back to where it was at the end of a test. Otherwise you end up with state that is shared between tests which is a bad thing.
Jack is a mocking framework that helps solve this problem. It’s not perfect but it is good enough for what I wanted to do.
Enough introduction, let’s start with the story that I’ve implemented. The link to the complete source code is located at the bottom of this post.
There is a simple form and we have to write client side validation logic for it. The rules are as follows:
- The user can select either one or more predefined reasons or can provide a custom reason. The user can not use both.
- If the form validation succeeds then the user gets a popup with “Correct” message
- If the form validation fails then the user gets a popup with “Wrong” message.
This is how the form looks like:
and this is the HTML behind it:
To be able to run the unit tests we have to have an HTML page that simply loads all required Java Script code and executes it.
As you can see the HTML page is very simple. It loads a few files that belong to YUI framework, then it loads code under test from
Form.js and the actual unit tests from
UnitTests.js.
Below is the content of
UnitTest.js file.
and the end result in a web browser:
The only thing that requires explanation here is the difference between Validation and Submission tests. The
validate method is a standalone method that does not have any dependencies hence its unit testing is very simple and boils down to passing different sets of input parameters and asserting the correct results.
The unit testing of the
submitForm method on the other hand is not that simple because the method relies on
getPredefinedReasons and
getCustomReason methods that grab data from the DOM and
validate method that ensures that the user provided data is valid. We are not interested in the way those methods work while unit testing
submitForm method. They actually gets in the way. What we need to do is to mock them and focus on making sure the
submitForm method shows correct messages to the user.
The mocking framework takes care of that. All we have to do is create an anonymous method that encapsulate all our mocking logic. The mocking framework will make sure that once the test is done the global state gets rolled back to where it was before the test was executed. The way Jack is designed reminds me of
using and
IDisposable in C#.
As you can see the jQuery based code is encapsulated into getXXX methods which makes easy to mock them. Some people don’t mock jQuery and instead try to recreate enough DOM elements on the test page to satisfy the tests. I don’t like this approach because changes to either HTML or jQuery might force us to change the unit tests which makes them brittle. It is like using L2S in a unit test. It’s not a unit test, it is an integration test. Other approach I’ve seen is to mock jQuery methods one by one. This is a slightly better approach but still changes to jQuery queries can break the tests. It is like trying to mock a sequence of Linq extension methods. It’s way easier to mock the whole method that simply encapsulates the query.
If this was a C# code then getXXX methods would be defined on some kind of repository and validate method would belong to a validation component. Both of them would be injected to the main logic that handles the form submission. If this was an ASP.NET MVC app that would be a controller. It was not my intention to structure the code in this way but that’s what I ended up with writing the tests first.
You might wonder why I haven’t shown the actual code yet. Well, I did it on purpose. The unit tests should be enough to understand what the client side code does and what its desired behaviour is. If this is still not clear then it means that either the code is not structured properly or that the names are not descriptive enough.
And that would be it. The last thing to do is to show the actual code:
