19.12. Test Driven JavaScript Development

A couple of weeks ago, I was attending a three-day workshop for agile developer skills. The workshop was split into five topics: Colaboration, Refactoring, Design & Architecture, Continious Integration and Test Driven Development. Especially the session about Test Driven Development was very interesting. Although I know the principles of TDD I was really impressed by the demonstration of solving a simple exercise (a coding kata) done in Java by the instructors of the workshop. It was not so much the coding in Java that was interesting for me, it was the combination of writing a test, executing the test with a shortcut from the IDE, see the test fail, write the implementation and re-start the test again within the IDE. You will say “that´s test driven development- it´s nothing new!” and you are right! But is there a way to do Test Driven Development in the same way for JavaScript? I mean writing a test, execute the tests with a shortcut from the IDE, see the test fail, implement the method and re-start the test? Yes, there is a way! So let me show you what I have done to do the same coding kata (called Fizzbuzz) with JavaScript.

Tools of trade

As I mentioned before, you need an IDE, for this article I choose JetBrains WebStorm 2.1- Zend Studio 8 or PHPStorm 2.* are also possible (these are the other tools I´ve given a try and it was also working). Now do we need a way to execute our tests – switching to a browser and refreshing a testsite is cheating at this moment although it would work anyway! What we need is anything to trigger the execution of the tests from the IDE (as the guys from the workshop have done). Therefore we need jsTestDriver, a testframework combined with a test server. By the way, I have written an article about integrating jsTestDriver into your continious integration environment during the Mayflower advent calendar series, maybe this will be also interesting for you. Coming back to our setup for the test driven development session. You can easily integrate jsTestDriver as a plugin into WebStorm (this plugin is also available for Zend Studio and PHPStorm).

Before we can start we should do a small but really useful configuration task. I will add the jsTestDriver assertion framework (or syntax) to the supported JavaScript libraries of WebStorm. You can do this by writing the definition of our test class. WebStorm detects the different syntax and suggests to add the support of jsTestDrivers assertion framework. I think this is useful step, because you can use the code completion for your asserts and shortcuts too.

Adding the jsTestDriver assertion framework to your supported libraries…

… will help you in many situations, e.g. for a smart code completion

Preconditions

We need two JavaScript files and one configuration file for jsTestDriver. The one JavaScript file is for the real implementation of our coding kata and the other one is for our test cases. The simple configuration file includes only these lines of code to describe where to find the needed source code:

Start your engine(s)…

Before I will write the first test, I need to start the jsTestDriver server (local) and add a browser to the list of test browsers. This is called capture and will be done by opening the URL with a browser of your choice, for this first scenario I choose Googles Chrome and Firefox. By the way it´s also possible to capture a remote browser, e.g. an Internet Explorer running on a virtual image.

At the moment the server is not running

Now the server is running and two browsers are captured

From this point our engines are running and we can start working on the coding kata. The kata called Fizzbuzz want us to substitute all numbers from 0 to 100 that are divisible by three with fizz, all numbers divisible by five with buzz and all numbers divisible by fifteen with fizzbuzz.

Test driven development

The test driven development process is an iterative process where each iteration consists of these steps:

• Write a test
• Execute the tests and watch the (new) test fail
• Make the test pass
• Refactor to remove duplication

Let´s begin with a first test. For this you can write the test by hand or you use the shortut ctrl+N on Mac or Alt+Insert on any other operating system for creating a stub of new testcase.

This function generates a new testcase for you

I prefer the shortcut and I called the test case „test say fizz“. My first pretty simple testcase looks like this:

You might think writing such easy tests will be senseless and not worth doing it, but that´s not true. It´s one of the key concepts of test driven development to do small steps and iterate in more steps to the right solution.

Next step: execute the test!
Since we have everything set up properly we can either use another shortcut to run the tests (shift + ctrl + F10) or press the run button at the header toolbar. In addition, you can use the contextual operation of the config-file “RUN” as well. We learn two things from our first test run – first, we see that we can trigger the execution of the tests from our IDE- thats great! Secondly, our tests fails- not so great! But ok, as we haven’t actually coded anything yet, so let´s make our test green!

Since there is no function play() the test fails

I implemented a first method play() which says fizz. Restarting the tests with my new learned (and loved) shortcut – cool, our tests are green!

Well done! Our first test runs fine.

For my next babystep I will write a test for any other number unlike three, five or fifteen. Once again I use the shortcut ctrl+N to generate a new testcase and write down another short assertion.

As you can imagine, this this will fail- and you are right. Executing this test will turn the lamp red, our test fails. We have to do a small change in our fizzbuzz function to turn the lamp green, look at this lines of ode:

I have done the first iteration and a first part of the specification is implemented, now it´s up to you to finish this pretty easy kata I will not copy and paste the next lines of code and screenhsots here.

Conclusion

In this blog post I have shown a way to use your IDE as a powerful helper for test driven JavaScript development. Kent Beck, godfather of extreme programming mentions in his book Test-Driven Development by Example, that the goal of TDD is „Clean code that works“ and he is right, because the short iterations allow for more instant feedback on the code. In addition, bad design decisions are easier to catch, you will write cleaner interfaces and as a welcome side effect you will get a good test coverage.
Compared with the IDE support of a mature programming language it´s pretty cool to have the possibility of writing and executing tests from the IDE for JavaScript too.

Links/Sources

• Coding Katas
• jsTestDriver
• WebStorm
• Book: Test Driven Development: By Example- Kent Beck