What were my requirements when I chose the tools that I will describe to you in this post? Actually, I needed tools which can provide me the same comfort that I have while I am developing in TDD with .NET. Precisely, the test should be run individually (or at least individually for a given set). They should be run on the continuous integration build, which is teamcity in my case. The test runner may use any browser for executing the tests even if flexibility for using all kind of browsers would be appreciated. In addition, the test should be easily debugged and this is a very important aspect for me.
Let me detail a little this latter requirement. Indeed, I have read recently this blog post and its written that
Debugging the tests
Wiseman said: “If you need to debug unit test then something is wrong with it’s unitness.”
Even if the rest of the blog is brilliant, I do not agree at all with this sentence. If you practice regularly TDD then you’ll see that you have to debug, that’s part of the game. If you never have to debug maybe it’s because you are asserting too much trivialities and not enough your own complex logic. In addition, if you have to create the webpage on your own, for debugging, that is not acceptable to me either. You should be able to put your breakpoint anywhere in your code and hit it in less than five seconds. We will see that the tool chosen permits such quick debugging and that’s the main reason why I am using it.
You may retrieve the code samples below on my github repository.
To illustrate these tools we will use a very simple mockup project and we start its description with the following VisualStudio solution.
The Visual Studio solution describing the example of this post.
We will take a very simple example, where the object app.sut has a function for computing the factorial of an integer. The code of sut.js can be found in the following snippet.
(Note that in app we have implemented a basic namespacing function such as this one)
Let us now focus on the test suite in the sutTests.js code.
This piece of code is very basic Jasmine syntax for a test suite. We assert the values of the factorial function for the two corner cases where the input is 0 and 1 and we also test the situation with n=5. Remark also that we have a test which asserts that an exception is thrown when a non positive value is passed to the function. We have not covered this situation with the snippet above, consequently, we expect this test to fail… Remark that all the needed references to js files are handled with ///<reference of Visual Studio. By the way, we benefit from Visual Studio Intellisense here.
In the next screen shot, we run the tests with the Visual Studio Test Explorer that is compatible with Jasmine thanks to Chutzpah.
Run all our test with the Visual Studio test explorer. As expected we encounter a failure.
Chutzpah Visual Studio extension creates web page for running/debugging tests in the web browser.
Then the debugging sessions happens in your browser (here Chrome). Clicking again the links reexecute the tests.
Now, we do have all the material for editing efficiently tests in Visual Studio. Let us have a few words for running the test using the command line on the server. Personally, I embed the Chutzaph runner in a /build directory within my sources and executes the following Powershell script.
Here is what it looks when ran it an Powershell console with teamcity options.
To conclude, I would say that Chutzpah is a great project and if you need a simple and ready to use test runner I would recommend it. The only limitation for now would be that the runner only supports phantomJS. However, you may use another another test runner for executing the tests with different browser and you can keep the Chutzpah Visual Studio extension for the development. One last important thing to note is the fact that Chutzpah 3.0 supports RequireJs.