Unit testing is not a new concept in the software development world. Thanks to Kent Beck, the concept of unit testing was introduced in Smalltalk , then the concept was transferred to many other programming languages, such as C, C++, and Java. The classical definition of unit testing is that it is a piece of code (usually a method) that invokes another piece of code and later checks the correctness of some assumptions.

The definition is technically correct; however, it does not show us how to make a really good unit test. In order to write a good unit test, we need to understand the requirements of a good unit test.

As shown in the following figure, a good unit test should be automated, repeatable, easy to understand, incremental, easy to run, and fast.

A good unit test should be automated and repeatable, which means that other team members can repeat running the application unit tests for every significant code change automatically. It should also be easy to understand so that other team members can understand what your test means and can continue adding more test cases or updating an existing test case. A good unit test should be incremental; this means that the unit test should be updated if a new relevant defect is detected in the code, which means that this defect will not happen again as long as this unit test is running periodically. Finally, a good unit test should be easy to run; it should run by executing a command or by clicking a button and should not take a long time for execution because fast unit tests can help in increasing the development team's productivity.

So let's go back to the definition and refine it. Unit testing is a piece of code (usually a method) that invokes another piece of code and checks the correctness of some assumptions later. Unit testing should be automated, repeatable, easy to understand, incremental, easy to run, and fast.

Unit testing applications is not something nice to have. It is actually a mandatory activity for having a successful software solutions that can cope with different changes across time with high stability. There is no excuse to skip unit testing of applications even for projects with a tight schedule. The importance of unit testing may not appear in the early stages of the project; however, its advantages are visible in the middle and the final stages of the project, when the code gets complicated, more features are required, and more regression defects appear (defects that appear again after a major code change).

Without unit testing, the integration of the different components in the system becomes complicated. This complexity results from the tracing of the defects of not only the integration between the components but also each "buggy" component. This complicates the life of the developers by making them spend nights in the office in order to meet the schedule.

The number of new defects and the regression defects becomes unmanageable when the code base becomes complicated and unit testing is not available. The developer can resolve a specific defect and, after a set of code changes, this defect can happen again because there is no repeatable test case to ensure that the defect will not happen again.

Having more number of defects per lines of code affects the application's quality badly, and this means that more time has to be spent on testing the application. Bad quality applications have a longer test cycle for each project deployment (or phase), because they have a high probability of having more defects for every code change, which leads to more pressure on the project management, the project developers, and the project testers.

Having good unit testing can be a good reference for the system documentation because it contains the test scenarios of the system use cases. In addition to this, unit testing shows how the system APIs are used, which reflect the current design of the system. This means that unit testing is a powerful basis of code and design refactoring for having more enhancements in the system.

Having good unit testing minimizes the number of regression defects because in good unit testing the system has a repeatable number of test cases for every relevant defect. Having a continuous integration job that runs periodically on the application unit tests will ensure that these defects will not happen again, because if a specific defect appears again due to a change in the application code, then the developer will be notified to fix the defect and ensure that the test case of this defect passes successfully.

As a result of reducing the regression defects, having good unit testing reduces the test cycle for each phase (or system deployment). In addition to this, the application can have more and more features per iterations or phases peacefully without worrying if these features shall break an existing module that has good unit tests.

There are two known approaches in writing unit tests for applications. The first approach prefers writing unit tests after writing the actual application code and this approach is called traditional unit testing . The second approach prefers writing unit tests before writing the actual application code, and this approach is called Test-Driven Development (TDD) or the Test-First approach.

As shown in the following figure, traditional unit testing is about writing the application code first. It can simply be a class or a method. After writing the piece of code, the unit tests, which test the functionality of the code, are written. Then the unit tests run. If the unit tests fail then the developer fixes the defects and runs the unit tests again. If the unit tests succeed then the developer can either refactor the code and run the tests again or continue to write the next piece of code and so on.

As shown in the following figure, TDD starts by writing a failing unit test to indicate that the functionality is missing. After writing the unit test, the unit test must be run to ensure that it fails. After that, the developer writes the application code that meets the unit test expectation. The unit test must be run again to ensure that it succeeds. If it fails then the developer fixes the bugs and if it succeeds the developer can either refactor the application code or continue writing the next test case.

TDD is a powerful technique, as it can give you more control on the application code and design; however, it is a double-edged sword because if it is done incorrectly, writing the tests can waste a lot of time and the schedule of the project can slip. Finally, either you are using TDD or traditional unit testing technique. Don't forget to make your tests automated, repeatable, easy to understand, incremental, easy to run, and fast.

Testing JavaScript applications is complex and requires a lot of time and effort. Testing JavaScript applications requires the tester to test the application on different browsers (Internet Explorer, Firefox, Safari, Chrome, and so on). This is because the JavaScript code that runs on a specific browser will not necessarily work on another browser.

Testing existing JavaScript web applications (with many web pages) on new browsers that are not supported by the application code is not a flexible process. Supporting a new unsupported browser means allocating more time for testing the application again on this new browser and for the new/regression defects to be fixed by the developers. Let's see a simple Broken JavaScript example, which illustrates this idea. In this example, the user enters his/her name and then clicks on the Welcome button. After that the welcome message appears.

The following code snippet shows the broken JavaScript example:

<!DOCTYPE html>
<html>
<head>
  <title>Broken JavaScript Example</title>
  <script type=»text/javascript»>
    function welcome() {
      var userName = document.getElementById(«userName»).value;
      document.getElementById(«welcomeMessage»).innerText = «Welcome «   + userName + «!»;
    }
  </script>  
</head>
<body>
  <h1>Broken JavaScript Example</h1>
  
  <label>Please enter your name:</label>
  <input id=»userName» type=»text» /><br/>
  <input type=»button» onclick=»welcome()» value=»Welcome»></input><br/><br/>
  <div id=»welcomeMessage»/>

</body>
</html>

If you run the code shown in the previous code snippet, you will find that it works fine in Internet Explorer (IE) and Safari while it does not work in Firefox (to be more specific, this example works on Internet Explorer 8 and Safari 5.1, while it will not work on Firefox 3.6). The reason behind this problem is that the innerText property is not supported in Firefox. This is one of the hundreds of examples that show a code that works in a specific browser while it does not work in another one.

As a result of these complexities, testing JavaScript code requires a good unit testing tool, which provides mechanisms to overcome these complexities. The good JavaScript unit testing tool should be able to execute the test cases across all of the browsers, should have an easy setup, should have an easy configuration, and should be fast in executing the test cases.

Now, let's move to the weather forecasting application. The weather forecasting application is a Java web application that allows the users to check the current weather in different cities in the world. The weather forecasting application contains both synchronous and asynchronous (Ajax) JavaScript code, which we will test in the later chapters of the book using the different JavaScript unit testing frameworks.

The weather forecasting application mainly contains three use cases:

The weather forecasting application is a Java web application. The server-side part of the application is written using Java servlets (http://docs.oracle.com/javaee/6/tutorial/doc/bnafd.html). If you are not familiar with Java servlets, do not worry. This book focuses only on JavaScript unit testing; all you need to know about these servlets is the functionality of each one of them, not the code behind it. The functionality of each application servlet will be explained during when the JavaScript code is explained, to show you the complete Ajax request life cycle with the server.

Another thing that needs to be mentioned is that the weather application pages are .jsp files; however, 99 percent of their code is pure HTML code that is easy to understand (the application pages code will be explained in detail in the next section).

The first screen of the application is the login screen in which the user enters his username and password, as shown in the following screenshot:

When the user clicks on the Login button, there is a JavaScript login client that ensures that the username and the password are entered correctly. If the username and the password are correct, they are submitted to the server, which validates them if the user is registered in the application. If the user is registered in the application then the user is redirected to the weather checking page; otherwise an error message appears to the user.

The username field must not be empty and has to be in a valid e-mail address format. The password field also must not be empty and has to contain at least one digit, one capital, one small character, and at least one special character. The password length has to be six characters or more.

In the weather checking page, the user can select one of the available cities from the combobox, then click on the Get weather condition button to get the current weather information of the selected city, as shown in the following screenshot:

In the user registration page, the user can register in the application by entering his username and confirmed password, as shown in the following screenshot:

When the user clicks on the Register button, the registration client's JavaScript object ensures that the username and the passwords are entered correctly. The registration client uses the same rules of the login client in username and password validations. It also ensures that the confirmed password is the same as the entered password.

If the user's registration information is correct, the username and passwords are submitted to the server. The user information is registered in the system after performing server-side validations and checking that the user has not already registered in the application. If the user is already registered in the system then an error message appears to the user.

<form class="box login" action="/weatherApplication/LoginServlet" method="post">
  <fieldset class="boxBody">    
    <label for="username">Username  <span id="usernameMessage" class="error"></span></label>
    <input type="text" id="username" name="username"/>
    
    <label for="password">Password  <span id="passwordMessage" class="error"></span></label>
    <input type="password" id="password" name="password"/>
  </fieldset>        
  <div id="footer">
    <label><a href="register.jsp">Register</a></label>    
    <input id="btnLogin" class="btnLogin" type="submit" value="Login" onclick="return validateLoginForm();"/>      
  </div>        
</form>

function validateLoginForm() {
  var loginClient = new weatherapp.LoginClient();
  
  var loginForm = {
    "userNameField" : "username",
    "passwordField" : "password",
    "userNameMessage" : "usernameMessage",
    "passwordMessage" : "passwordMessage"
  };
  
  return loginClient.validateLoginForm(loginForm);
}

if (typeof weatherapp == "undefined" || !weatherapp) {
  weatherapp = {};
}

weatherapp.LoginClient = function() {};

weatherapp.LoginClient.prototype.validateLoginForm =  function(loginForm) {
  
  if (this.validateEmptyFields(loginForm) && 
      this.validateUserName(loginForm) && 
        this.validatePassword(loginForm)) {
    
    return true; 
  } 
  
  return false;
};

if (typeof weatherapp == "undefined" || !weatherapp) {
  weatherapp = {};
}

weatherapp.LoginClient.prototype.validateEmptyFields =  function(loginForm) {
  var passwordMessageID = loginForm.passwordMessage;
  var userNameMessageID = loginForm.userNameMessage;
  
  var passwordFieldID = loginForm.passwordField;
  var userNameFieldID = loginForm.userNameField;
  
  document.getElementById(passwordMessageID).innerHTML = "";
  document.getElementById(userNameMessageID).innerHTML = "";  
  
  if (! document.getElementById(userNameFieldID).value) {
    document.getElementById(userNameMessageID).innerHTML = "(field is required)";
    
    return false;
  }
  
  if (! document.getElementById(passwordFieldID).value) {
    document.getElementById(passwordMessageID).innerHTML = "(field is required)";

  return false;
  }
  
  return true;
};

weatherapp.LoginClient.prototype.validateUserName = function(loginForm) {

  // the username must be an email...
  var userNameMessageID = loginForm.userNameMessage;
  var userNameFieldID = loginForm.userNameField;  

var userNameRegex = /^[_A-Za-z0-9-]+(\.[_A-Za-z0-9-]+)*@[A-Za-z0-9]+(\.[A-Za-z0-9]+)*(\.[A-Za-z]{2,})$/;  
  var userName = document.getElementById(userNameFieldID).value;

if(! userNameRegex.test(userName)) {
    document.getElementById(userNameMessageID).innerHTML = "(format is invalid)";
 
return false;
}  
    
    return true;    
};

weatherapp.LoginClient.prototype.validatePassword = function(loginForm) {
  
  // the password contains at least one digit, one capital and small character 
  // and at least one special character, and 6 characters or more...
  var passwordMessageID = loginForm.passwordMessage;
  var passwordFieldID = loginForm.passwordField;
  
  var passwordRegex = /((?=.*\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[@#$%]).{6,20})/;
  var password = document.getElementById(passwordFieldID).value;  
  
  if (! (passwordRegex.test(password) && password.length >= 6)) {
    document.getElementById(passwordMessageID).innerHTML = "(format is invalid)";
    
    return false;
  }  
  
  return true;
};

<h1>Welcome to the weather application</h1>
<FORM method="post">
  <label class="label" for="postalCode">Select the Location: </label>
  <select id="w" class="selectField">
    <option value="1521894">Cairo, Egypt</option>
    <option value="906057">Stockholm, Sweden</option>  
    <option value="551801">Vienna, Austria</option>
    <option value="766273">Madrid, Spain</option>  
    <option value="615702">Paris, France</option>
    <option value="2459115">New York, USA</option>
    <option value="418440">Lima, Peru</option>            
  </select>     
  
  <input type="button" class="button" onclick="invokeWeatherClient();" 
             value="Get weather condition"/>
  <br/><br/>
             
  <div id="weatherInformation" class="weatherPanel">
  </div>
</FORM>

function invokeWeatherClient() {
  var weatherClient = new weatherapp.WeatherClient();
  var location = document.getElementById("w").value;  
  
  weatherClient.getWeatherCondition({
    'location': location,
    'resultDivID': 'weatherInformation'
  }, 
weatherClient.displayWeatherInformation, 
weatherClient.handleWeatherInfoError);    
}

if (typeof weatherapp == "undefined" || !weatherapp) {
  weatherapp = {};
}

weatherapp.WeatherClient = function() {};
weatherapp.WeatherClient.xmlhttp;
weatherapp.WeatherClient.weatherForm;
weatherapp.WeatherClient.endpointURL = "";

weatherapp.WeatherClient.prototype.getWeatherCondition =  function(weatherForm, successCallBack, failureCallBack) {
  
  if (window.XMLHttpRequest) {
    this.xmlhttp = new XMLHttpRequest();
  } else {
    this.xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
  }
  
  var successCallBackLocal = successCallBack;
  var failureCallBackLocal = failureCallBack;  
  var weatherClientLocal = this;
  
  this.xmlhttp.onreadystatechange = function() {
weatherClientLocal.weatherInformationReady(successCallBackLocal, failureCallBackLocal);
  };
  
  this.weatherForm = weatherForm;
  
  if (typeof this.endpointURL == "undefined") {
    this.endpointURL = "";
  }
  
  this.xmlhttp.open("GET", 
          this.endpointURL + 
          "/weatherApplication/WeatherProxyServlet?w=" + weatherForm.location + "&preventCache=" + new Date().getTime(), 
          true);
  
  this.xmlhttp.send();  
};

weatherapp.WeatherClient.prototype.weatherInformationReady =  function(successCallBack, failureCallBack) {  
  if (this.xmlhttp.readyState != 4) { 
    return; 
  }
  
  if (this.xmlhttp.status != 200)  {
    failureCallBack(this);

return;
      }
    
  if (this.xmlhttp.readyState == 4 && this.xmlhttp.status == 200) {
    successCallBack(this);
      }
};

weatherapp.WeatherClient.prototype.displayWeatherInformation =  function(weatherClient) {
  var resultDivID = weatherClient.weatherForm.resultDivID;
  
document.getElementById(resultDivID).innerHTML = weatherClient.xmlhttp.responseText;
};

weatherapp.WeatherClient.prototype.handleWeatherInfoError =  function(weatherClient) {
  var resultDivID = weatherClient.weatherForm.resultDivID;
  
  alert ("Error: " + weatherClient.xmlhttp.responseText);  
document.getElementById(resultDivID).innerHTML = "Error: " + weatherClient.xmlhttp.responseText;  
};

<form class="box register" method="post">      
  <fieldset class="boxBody">      
        
<label for="username">Username (Email)  <span id="usernameMessage" class="error"></span></label>
    <input type="text" id="username" name="username"/>
    
<label for="password1">Password  <span id="passwordMessage1" class="error"></span></label>
    <input type="password" id="password1" name="password1"/>

    <label for="password2">Confirm your password</label>
    <input type="password" id="password2" name="password2"/>
    
  </fieldset>        
  <div id="footer">
    <label><a href="login.jsp">Login</a></label>    
<input id="btnRegister" class="btnLogin" type="button" value="Register" onclick="registerUser();" />
  </div>      
  
</form>

function registerUser() {
  var registrationClient = new weatherapp.RegistrationClient();
  
  var registrationForm = {
    "userNameField" : "username",
    "passwordField1" : "password1",
    "passwordField2" : "password2",        
    "userNameMessage" : "usernameMessage",
    "passwordMessage1" : "passwordMessage1"
  };
  
  if (registrationClient.validateRegistrationForm(registrationForm)) {
    
    registrationClient.registerUser(registrationForm, 
                     registrationClient.displaySuccessMessage, 
                          registrationClient.handleRegistrationError);
  }
}

if (typeof weatherapp == "undefined" || !weatherapp) {
  weatherapp = {};
}

weatherapp.RegistrationClient = function() {};
weatherapp.RegistrationClient.xmlhttp;
weatherapp.RegistrationClient.endpointURL = "";

weatherapp.RegistrationClient.prototype.validateRegistrationForm =  function(registrationForm) {  
  var userNameMessage = registrationForm.userNameMessage;  
  var passwordMessage1 = registrationForm.passwordMessage1;
  
  var userNameField = registrationForm.userNameField;  
  var passwordField1 = registrationForm.passwordField1;
  var passwordField2 = registrationForm.passwordField2;  
  
  var password1 = document.getElementById(passwordField1).value;
  var password2 = document.getElementById(passwordField2).value;
  
  // Empty messages ...
  document.getElementById(userNameMessage).innerHTML = "";  
  document.getElementById(passwordMessage1).innerHTML = "";  
  
  // create the loginClient object in order to validate fields ...
  var loginClient = new weatherapp.LoginClient();
  
  var loginForm = {};
  
  loginForm.userNameField = userNameField;
  loginForm.userNameMessage = userNameMessage;
  loginForm.passwordField = passwordField1;
  loginForm.passwordMessage = passwordMessage1;    
  
  // validate empty username and password fields.
  if (! loginClient.validateEmptyFields(loginForm)) {
    return false;
  }
  
  // validate that password fields have the same value...
  if (password1 != password2) {
document.getElementById(passwordMessage1).innerHTML = "(Passwords must be identical)";
  
    return false;
  }
  
  // check if the username is correct...  
  if (! loginClient.validateUserName(loginForm) ) {
document.getElementById(userNameMessage).innerHTML = "(format is invalid)";
    
    return false;
  }
  
  // check if the password is correct...
  if (! loginClient.validatePassword(loginForm) ) {
document.getElementById(passwordMessage1).innerHTML = "(format is invalid)";
    
    return false;
  }  
  
  return true;    
};

weatherapp.RegistrationClient.prototype.registerUser =  function(registrationForm, successCallBack, failureCallBack) {
  var userNameField = registrationForm.userNameField;  
  var passwordField1 = registrationForm.passwordField1;
  var passwordField2 = registrationForm.passwordField2;  
  
  var userName = document.getElementById(userNameField).value;    
  var password1 = document.getElementById(passwordField1).value;
  var password2 = document.getElementById(passwordField2).value;
  
  if (window.XMLHttpRequest) {
    this.xmlhttp = new XMLHttpRequest();
  } else {
    this.xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
  }
  
  var successCallBackLocal = successCallBack;
  var failureCallBackLocal = failureCallBack;  
  var registrationClientLocal = this;
  
  this.xmlhttp.onreadystatechange = function() {
registrationClientLocal.registrationReady(successCallBackLocal, failureCallBackLocal);
  };
  
  if (typeof this.endpointURL == "undefined") {
    this.endpointURL = "";
  }
  
  this.xmlhttp.open("POST", 
            this.endpointURL + 
            "/weatherApplication/RegistrationServlet", 
             true);
  
this.xmlhttp.setRequestHeader("Content-type","application/x-www-form-urlencoded");
  
  this.xmlhttp.send(userNameField + "=" + userName + "&" +
            passwordField1 + "=" + password1 + "&" +
            passwordField2 + "=" + password2);  
};

weatherapp.RegistrationClient.prototype.registrationReady =  function(successCallBack, failureCallBack) {  
  if (this.xmlhttp.readyState != 4) { 
    return; 
  }
  
  if (this.xmlhttp.status != 200)  {
    failureCallBack(this);
return;
}
    
  if (this.xmlhttp.readyState == 4 && this.xmlhttp.status == 200) {
    successCallBack(this);
      }
};

weatherapp.RegistrationClient.prototype.displaySuccessMessage =  function(registrationClient) {
  alert("User registration went successfully ...");
};

weatherapp.RegistrationClient.prototype.handleRegistrationError =  function(registrationClient) {
  alert(registrationClient.xmlhttp.responseText);
};

$CATALINA_HOME\bin\startup.bat 

$CATALINA_HOME/bin/startup.sh

$CATALINA_HOME\bin\shutdown.bat  

$CATALINA_HOME/bin/shutdown.sh

In this chapter, you learned what unit testing is, the requirements of a good unit test, and why we need unit testing. You got to know the difference between the Test-Driven Development and the traditional unit testing. In the JavaScript world, you understood the complexities of testing JavaScript code, and the requirements of good JavaScript unit testing tools. At the end of this chapter, I explored with you the weather web application use cases and its JavaScript code in detail, which we will unit test in the later chapters. In the next chapter, you will learn how to work with the Jasmine framework and how to use it for testing the weather application.