Mayflower Blog

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.

Nearly every PHP project comes up with a great set of tools to assure the quality of source code; unit tests are a no longer a „nice to have“ feature, they are common components in new projects. While unit tests help you to provide solid interfaces and proof the functionality of a certain method, there is a long list of tools that check the quality of the source code itself with many different metrics. Each of these mentioned tools reports its results into a XML file, which can easily be interpreted by a continuous integration server like Jenkins. The benefit is enormous: After every commit to your version control system your continuous integration server triggers the execution of the tests and the source code quality analysis and shows the result in meaningful diagrams. As a developer you get a direct feedback and you can make a prediction on the status of the entire project, because if even the smallest units work fine, there is a good chance that the whole system runs stable.

So far for developing with PHP, but what about JavaScript? Are there any tools for quality assurance? Yes! Is it really necessary to do JavaScript QA? Oh yes! Since JavaScript is becoming one of the hottest programming languages for web (and mobile) development, there is no doubt that that we need some way to check the functionality and measure the code quality. Before I will show you some really cool tools and some easy steps on how to set up your own quality assurance environment, let me say a few words on how the increasing popularity of Javascript is affecting the requirements we have on QA for JavaScript and how it is different to QA for PHP. . A couple of years ago, JavaScript was only used for some (unneeded) animation, called DHTML, and for simple form validations. The AJAX hype gave JavaScript a second chance and from this point the lines of JavaScript code where spreading. In other words, most developers haven´t seen the necessity of writing down something similar to unit tests only for some small piece of JavaScript code, they use Firebug for debugging and it works fine for the moment. Another reason why JavaScript QA is different from PHP QA lies in the nature of JavaScript. Whereas PHP is mostly executed on a (Apache) server JavaScript is executed on many different environments and devices that don´t follow common rules and standards. That´s why the requirements for any QA tools are really difficult, because you want to cover a huge amount of environments and devices- otherwise you can only guaranty that your source code runs correctly on a certain device and I´m sure that´s not your intention. In addition, don´t forget the dynamic of JavaScript. It´s easy to extend the range of functions of JavaScript (because of it´s prototypical inheritance) or think of all the functions that come up with the environment, for example the Firefox File API. All these dynamic is really really hard to cover for QA. And last but not least, JavaScript is an interpreted language not a compiled one, this means there is no static code analysis that check the syntax tree like it's done during compiling in other programming languages. So we have indicated two very simple requirements for JavaScript quality assurance: we need something to check our syntax and we need something that tests our code with many different environments/browser and devices. Ok, enough for the moment, let´s introduce our first tool: jsLint.

jsLint
This is not a completely new tool, invented by Douglas Crockford, jsLint is a JavaScript syntax parser written in JavaScript that does not need a browser for its syntax checks. You can use jsLint in many different ways, I prefer the Java wrapper for jsLint as a command line tool, see jslint4java [http://code.google.com/p/jslint4java/]. JsLint (and also jslint4java) comes up with a lot of possible optional parameters to define how strict your code should be checked.
Here is an first example of jsLint (called from the commandline via jsLint4java):

Not only syntax errors like the missing semicolon at the end of a line or a comma after the last entry of an array are considered, mixing spaces and tabs or a wrong indention will be checked as well. Using jsLint4java allows you to print the results into defined XML files. On the way to our own JavaScript QA environment we have entered our first milestone: We check our syntax tree with jsLint, in other words we do a static code analysis- cool!

From now on our source code quality will be checked by jsLint, but this doesn´t guaranty that our functions work well. This is the point where we should think about unit tests. There are a lots of great unit testing tools for JavaScript and nearly every frameworks comes up with its own implementation. To fit the requirement I have mentioned before, run the tests on many different environments (browsers) and devices, we need not only a standalone unit testing tool, we need something that runs the tests on these environments and devices. This is the point where our second tool enters the stage: please say hello to Googles jsTestDriver.

JsTestDriver
JsTestDriver is pretty easys to use it consist of a single JAR file which contains everything you need to get started. Here is an overview of how JsTestDriver works at runtime: This tool combines an independent test framework and a testrunner to execute the tests on many different environments and devices.
This is the general architecture of jsTestDriver

Therefore the tool starts a simple HTTP server to connect with your browser. From this point your browser is marked as a “browser to test”, this process is called “capturing”. There are only two steps left to run tests on the captured browsers. Step one is to write down some tests and step two is to trigger the execution of the tests from the command line of your system. Furthermore for jsTestDriver it doesn´t matter whether you are executing your tests from Windows, Mac or any Linux operation system you can capture a browser form any remote system or a mobile device. By the way, it´s not strictly needed to add a browser by visiting the “capture page”, it´s also possible to pass the path to the browser to an optional command line parameter (--browser). In this case jsTestDriver will open the browser, execute the tests and shut down the browser. For writing the tests jsTestDriver provides a huge amount of assertions but it´s also possible to write the tests with nearly every test framework of your choice by using an adapter for it. By starting the tests, all tests will be sent over HTTP to all captured browsers and executed, the results will be sent back to the server and will be displayed by default at the screen. An export of the results into a XML file is also possible.

Here is a short example how a test for jsTestDriver could look like
MathmaticsTest = TestCase("MathmaticsTest");
MathmaticsTest.prototype.testAdd = function() {
var mathmatics = new school.Mathmatics();
assertEquals(3, mathmatics.add(1,2));
}

MathmaticsTest.prototype.testSub = function() {
var mathmatics = new school.Mathmatics();
assertEquals(1, mathmatics.sub(4,3));
}

MathmaticsTest.prototype.testDiv = function() {
var mathmatics = new school.Mathmatics();
assertEquals(4, mathmatics.div(8,2));
}

MathmaticsTest.prototype.testMultiple = function() {
var mathmatics = new school.Mathmatics();
assertEquals(9, mathmatics.multiple(3,3));
}

Executing the tests ends in a result like this:



After knowing these two very nice tools we already have two major components for or QA environment. What is still missing? Running a static code analysis and triggering unit tests for different devices from the command line is pretty cool already, but it would be even cooler if we were able to integrate jsLint and jsTestDriver into a continuous integration environment to automate the process of checking and testing our source code. A couple of lines ago, I have mentioned Jenkins as one possible tool for continuous integration and do you remember that jsLint4java and also jsTestDriver have a XML output? Bingo! This is the great benefit of these two tools, they generate a XML file that could easily be read by Jenkins (or any other continuous integration tool). Imagine this workflow: You write some new JavaScript code including tests, you check in your changes into your projects version control system, Jenkins recognizes that there are some changes and triggers the static code analysis and starts the execution of the test and after performing these two tasks the results will be displayed in some nice graphs.Sounds promising, doesn't it? This is exactly what we will do with the next easy steps, because we only have to configure Jenkins- nothing more! Step one is to create an ANT task for each tool, this will be done in the projects build file (build.xml). A sample definition of an ANT task could be found at the homepage of jsLint4 [http://docs.jslint4java.googlecode.com/git/2.0.1/ant.html].



Important for this configuration is the node target with it´s attribute name, because this is the value you have to enter into the Jenkins configuration. In addition, see the jslint node, where you can configure the strength or weakness of your analysis via the attribute options. Whereas the node formatter defines where the XML output should be saved, the fileset node defines the directory with the source code file that should be checked. That´s all for jsLint. The task definition for jsTestDriver looks pretty similar:



This ANT task executes the tests on the defined browsers. Also it writes the output into the defined directory. And that´s all for the moment, all other needed steps have to be done in Jenkins, and that´s also easy.
Here the two needed steps:





And these are the results:










Conclusion
For this blogpost I have introduced two (free available) tools and showed the steps to build your own basic JavaScript QA environment with Jenkins for continuous integration. In summary what you will get with this setup is a solid environment for checking your source code quality and a way for automated unit test execution. Beside the presentation of the syntax violation results (jsLint) and unit tests (jsTestDriver) results I recommend a small subversion post commit hook that will send you an email with the results coming from jsLint. To conclude this blogpost, there is not only jsLint and jsTestDriver for measuring, checking and saving the quality of JavaScript code, for example it´s possible to use a plugin for jsTestDriver that checks the code coverage or define another ANT task that automatically generates a minified version of your source code.

A couple of years ago, PHP developers only had to have strong knowledge in the language itself and experience in some PHP frameworks and libraries, additionally skills in MySQL were expected. If we take a look at our current job advertisement, these knowledge is still important, but also skills in JavaScript are asked and strongly desired. If you wonder why JavaScript is so popular at these times, my answer is quite simple: The browser is no longer a stupid instrument to view some static websites on the internet- the browser turned into an (Web-) Application Platform that provides more content then plain text. This results in more and more complex sites and therefore in much more source code. One of the reasons for this progress is AJAX, which is the art of exchanging data with a server, and updating only parts of a website (with JavaScript). Therefore JavaScript is the big winner on this evaluation, because it is available on nearly every browser, needs no plug in or any additional software and it is easy to learn. In the early days of the internet we used JavaScript to create some lousy effects or did some simple checks for any input fields. These days are gone, it is not unusual to have more JavaScript code than PHP code in large projects. Coding with JavaScript is not the same as coding with PHP, that´s the reason why I will write down some typical pitfalls for a PHP developer whose coding JavaScript.

Data types
There are two major data types in JavaScript, the primitive one (Boolean, String, Number, ...) and Object (Array, Function). To check the data type the keyword typeof keyword might help you. But be aware! Objects are the fundamental units of JavaScript and virtually everything in JavaScript is an object and takes advantage of that fact. Even the primitive data types have so called “primitive object wrapper” and there´s great potential for wrong usage of the typeof keyword and checking the data type. Here is a small overview what you will get if you use the typeof keyword with several variables:

Variable	typeof Variable
{company: 'Mayflower'}	“object“
['Mayflower','PHP']	“object“
function(){}	“function”
“a simple String”	“string”
123456789	“number”
true	“boolean”
new String(“Mayflower”)	“object”
new Employe( )	“object”

You can see, you will not always get what you expect. Therefore it´s not always a good choice to check the data type with typeof. A better approach is to use the constructor property to identify the data type of a variable.

var myArr = [ ]; if (myArr.constructor === Array) {console.log(“yes, I am an Array!”)}

The downside of this approach is the needed comparison to a known data type. If you create your Array with the new operator, you can get the data type with the prototype property, like this:

var myArr = new Array(); console.log(myArr.prototype); // Array()

Array !== Array
In the PHP world an array is a wildly used data type and we are differ between the zero indexed, comma separated array and hash tables of key-value pairs, better known as associative arrays. In JavaScript an Array is just a simple zero indexed list of values- nothing more. There is no associative array in JavaScript. There is no trailing comma support for IE (causes an error)

var myArr = ['Mayflower','PHP','JavaScript'];

In JavaScript is something like an associative array, but this has nothing to do with the Array data type. The JavaScript world calls this an object literal and is a collection of key value pairs.

var obLiteral = {company: “Mayflower”, offices: ['München','Würzburg'] };

By the way, you are right if you say “the syntax looks like for a JSON string”. The syntax for an object literal and a JSON string are pretty similar with one main difference: For a JSON string the property names need to be wrapped in quotes to be valid. For object literals the quotes are only required if the property name have spaces or any other not valid identifiers.

for (… in … ) !== foreach
When you are working with Arrays the you surely know the foreach construct to iterate over the array. Against the common opinion, the for (… in … ) construct is not the JavaScript equivalent of foreach and it is not the best way to iterate over an array in JavaScript.
DO: Use the for (...) loop for iterations over array objects Every JavaScript array provides a length property, so it is the best practice for iterating over a JavaScript using a simple for construct.
DON´T: Use the for (… in …) loop for iterations over array objects It is not impossible to use the for (…. in … ) loop with an array (you remember, arrays are objects, too), but it can lead to some ugly errors because JavaScript is a powerful language and you can add functionality and properties to nearly every existing object (this is called augmentation). If you iterate over an augmented array object you will not get only the elements of the array, you will even get the augmented functionality and this may occur in an error.

The thing with the semicolon
Have you ever heard about “line termination with semicolon insertion”? JavaScript provides a mechanism that adds a semicolon to the end of a line if you forget it. At a first look this may be helpful but it can be the reason for endless debugging sessions. Imagine the following situation:

function user(){
return
{
company: “Mayflower”,
business: “PHP Development”
}
}

The user function will run without any error and will return a valid value (Ok, it´s undefined but it´s a valid return value). It´s not the desired object literal because the semicolon insertion terminates the function after the return.

I´m sure there are a lots of more pitfalls for PHP Developers, if you are interested in real crazy JavaScript I recommend a visit at http://wtfjs.com/.