One gun, many enemies

I spent some time, re-investigating Javascript. After few months of intensive TDD and SOLID training I was curious how those principles apply in slightly different environment. Guess what, they do not differ that much... I wanted to write about all this little later, after gathering some experience from battle ahead. However, Watirmelon post, invited me to attack this subject immediately.

I got through available testing frameworks for Javascript and decided on Jasmine. Why? Mainly because its syntax - BDD style which is fashionable this season. Second reason is that it has really cool documentation. Finally, basic set up was painless to me.


Let's look at basics - what I expect from different types of tests and how Jasmine fits into those requirements:

1. Unit Testing

Aims

1. Shoot them one by one
   (structure your code so that it is easier to maintain)
2. Be sure you kill with every shot
   (verify small bits of code to nail down bug issue)
3. Kill them all
   (verify edge cases)
4. Kill them quick
   (provide fast feedback on issues)

Choose gun which is

1. Fast shooting - the faster you shoot, the more enemies you will kill
   (unit tests must be blazing fast)
2. Reliable - your gun is stuck and you are dead
   (when unit tests are brittle you will stop depending on them)
3. Always close
   (unit tests are your gun, so you must be able to run them all locally)

Jasmine works great for all those aims, as it is really fast and it allows you to stub both objects and DOM elements. Keep in mind that Unit Testing is useful only if you either write new code or refactor old one. Do not ever try to write UT for a ready code which you don't intend to refactor. It's like shooting dead. You simply cannot kill them with another bullet.

2. Integration Testing

Aims

1. Beware of the hidden sniper
   (test against external dependencies like files, databases, network services)
   
2. You are part of your squad
   (verify that components of the application work well together)

Choose the right strategy

1. Observe the environment
   (try to use depenedencies as close to real problem as possible e.g. static file, database with test data, test version of a service)
2. Point in the right direction
   (do not try to test your stack top-down, instead concentrate on interfaces and adapters that you could not test in unit tests)

Integration tests will naturally be harder to quickly setup, they might broke due to configuration problems or inaccessible external services. That's why you don't want to have that many of them. Still, you want to know that all your problems are due to your partner changing protocol. Once again nothing stops us from using Jasmine here.

3. Acceptance Testing

Aims

1. Confirm you are fighting the right war
   (show specification to your product owner/manager/client)
2. Keep clean supply routes
   (test the functionality of your up with full set up and all dependencies)
3. Find hidden mines
   (test your application in all environments you deploy your application to)

Tips

1. Speak in their language
   (use tool which allows writing tests in natural language e.g. Cucumber or SpecFlow)
2. Take your time
   (those tests will be slower, so accept that you will not always run them locally)
3. Spend your resources wisely
   (acceptance tests are naturally much more brittle then other types of tests, so try to keep their number reasonably small)

This is where I would not recommend Jasmine, simply because it doesn't fit this job. It's syntax is based on programming language, so it is harder to read by non engineers. Jasmine allows you to execute events and call your code. However, your users will be most likely using a browser to interact with your code, so it is much better to use some tool that also uses browser to test web page.

Conclusion

I find Jasmine extremely well suited for unit and integration testing. I wouldn't use it for acceptance tests as there are quite few better tools for that job.

Post Scriptum (on DOM dependency)

On his blog Alister Scott also complains about integration issue between his server-side code and client-side code. His experience is that changes to ids and classes in mvc application result in not working javascript. The issue is serious and shows one important mistake which is hardcoding dependencies. Ids and class names are configurable details and Javascript code should be agnostic of them. To illustrtate let's look at test case for a very simple code from my pet-project:

    
describe("GameController", function(){
  describe("During Initialize", function() {
    var view;
    var subject;

    beforeEach(function() {    
        setFixtures("<div id="myid"></div>");
        subject = new GameView();

        subject.CreateFabricInDiv("#myid");
    });

    it("creates fabric in div", function(){
        expect($("#myid")).not.toBeEmpty();
    });

    it("holds pointer to canvas", function(){
        expect(subject._canvas).not.toBe(undefined);
    });
}); 

Do you see how "#myid" parameter is passed into method call? We moved configuration detail out from Javascript code. In my opinion it is simplest solution to Alister problem. This will enable keeping ids/classes consistent between code which generates them and Javascript that uses them. It also helps with code re-usability as you can use the same code on two separate pages with differing ids!