TomHarris.co.uk >> Blog

Sunday 27 October 2013

JavaScript testing

JavaScript testing has got to be one of the most overlooked areas of testing since practices like TDD and Unit testing begun. It is often seen as a code to just add events and load data, these days with HTML5 bringing new functionality I have seen more and more people use client side coding. People are seeing the benefit of client side processing and with the introduction of JavaScript workers in new browsers this is only going to continue. This code clearly has a place and therefore we need to start thinking about how we test this.

I have been working on web applications for ten years and in the past 3 years I have really bought into testing be it TDD or just unit test developed after. I believe it’s the stable to any long lasting project. The question I had to ask myself about a year ago was how I can ensure that my client side code is as stable as my server side code. Firstly it was a case of replacing all old legacy code with standard libraries like JQuery, this then left the community to support these areas. Also worth pointing out JQuery is tested.

That alone wasn't enough to get me coverage. I work on a system with complex calculations that process for nutrition and recipe data on the client. This data is critical to business process so has to be correct. We needed to make sure these and calculations similar where covered to our server side code. So I took on the task of testing our Client side code.

Now the idea of testing JavaScript isn't hard. Many solutions are out there to help you on this path, below are some examples. But the concept of testing something like JavaScript is the hard one. Below are some of the issues and solutions and my conclusion so far to how you can start testing.


DOM Interaction

So we have all inherited someone's code or even written sloppy code when we where juniors. Well often one of the key mistakes when starting out is the crossing over of JavaScript and the DOM. Now this is perfectly fine when you are working with a DOM manipulating library but when you come across a solution that does calculations and each time it gets the value from the DOM input this is a big "no no". When it comes to JavaScript testing, and really any testing, this has to stop. What we should be trying to do is pass a model to our method or parameters and get the result. With the result you can then bind this to the input DOM. This way when you run you test it can run without the DOM in place.

Server Calls

Next on my list of changes was the methods which hit the server. In the test environment I don't have the data set-up to ensure that my test pass. If I do have the data I cannot be sure it's the same each time. So what I need is to be able to simulate the server being hit, I need to mock the server. This is common practice in .NET development but maybe not obvious in JavaScript. The article below explains in detail the different libaries that are available and

http://testdrivenwebsites.com/2010/05/06/java-script-mock-frameworks-comparison/

Integrated builds

With any testing framework what we want is for it to be automated. Ideally this should happen on each check-in.  The below blog explains some of the more popular frameworks and getting them running in a automated fashion.

http://blog.danmerino.com/continuos-integration-ci-for-javascript-jasmine-and-teamcity/


Conclusion So Far
Again to point out this is my feelings so far, 6 months in. I'm sure as I move forward and so does the concept of JavaScript testing the decisions and problems will changes. I will try to keep this post updated with the latest.

For me JavaScript testing although it is firmly out there is still not at the maturity that allows a clear decision. Many libraries are available and its a constantly changing environment. It also depends on the set-up you have and the requirements.

If you are learning about testing and how to structure your code. I would start with QUnit its simple to setup and get going. You will however outgrow QUnit fairly quickly if you are working with multiple developers.

If you want the full feature set then go for Jasmine today it's more of a framework for testing than QUnit. It also appears to be a favourite with many developers. And some large libraries like AngularJS are being tested with this today.

No comments:

Post a Comment