WEB APP TESTING USING KNOCKOUT.JS

One of the most debated topics in software development is testing. There are a lot of different opinions about many aspects of software testing, from its role in the design process, to the execution frequency and codebase coverage. For example, in most of the agile methodologies, unit testing plays a primary role, but not all projects can follow a strict test-first process. We have to find the best trade-off between the development process principles and the stakeholder's environment.

Not every project is treated in the same way when we talk about software testing. From time to time, there are projects with a very low number of tests; not every part of the code base is covered by any kind of verification.

It happens, this is the real world, and it will continue to happen. However, this is not a healthy way to proceed. Basically, software testing is the proper way to prove that our solution:

There are contracts that consider that a project has concluded only in the presence of the appropriate documentation showing the correct system operation. To reach this objective, we need a solid testing strategy; this means that we need to carefully choose the following:

Every single topic in these bullet points carries years of professional experience; it's not easy and immediate to become an expert. I also have to say that not every project covers all the enlisted items because of budget, time, or team habits.

On the other hand, there are two main reasons that suggest introducing at least a basic testing coverage from the bottom:

This is a minimal scenario, but it's important to define a starting point, and I think this is the best place to begin a journey that will lead to a new way to consider software development.

This starting point is called unit testing, the first level of software testing; it works directly on the code and is usually the easiest to set up and learn.

This kind of testing should never be absent in any software solution. There are plenty of frameworks and libraries for the most important programming languages and Integrated Development Environments (IDEs); not writing tests is just a matter of will.

This book talks about web application testing, but it's not intended to be an exhaustive reference for software testing; more of a short manual, so we need to focus on unit testing. However, it's very important to understand that you should consider this book in a broader context, a piece in the jigsaw.

In particular, this is not a book that talks about Test Driven Development (TDD). TDD is a design methodology that leverages unit testing as the primary working tool. It's quite common to use TDD and unit testing as synonyms, but this is not correct. You cannot practice TDD without unit testing, but you can write unit tests without TDD and improve your design anyway.

In this book, I'd like to show what you need to do to set up a proper testing environment for a web solution, not teach you how to design your applications. Software design is a question of professional experience and involves a lot of general development aspects not specifically related to web development. On the other hand, what you will learn in this book is strictly related to the web application scenario, because we will talk about technical details, frameworks, and libraries that you can only find in web development.

By the way, you are welcome to apply TDD in web development using what you find in these chapters.

The Web has changed a lot since HTML5 made its appearance. We are witnessing a gradual shift from a classic full server-side web development to a new architectural asset that moves much of the application logic to the client side.

The general objective is to deliver rich internet applications (RIA) with a desktop-like user experience. Think about web applications such as Gmail or Facebook. If you maximize your browser, they look like full desktop applications in terms of usability, UI effects, responsiveness, and richness.

Usually, solution architecture is quite simple, a rich and complex user interface on the client side, some application services on the server side. The technology scenario is also very straightforward. On the client side, HTML5, JavaScript, and CSS3 are the emerging options. They are replacing older plugin technologies such as Adobe Flash and Microsoft Silverlight. On the server side, HTTP RESTful services are widely adopted because of their implementation simplicity and standardization across a large variety of programming languages.

This is the main technology trend. Maybe it's not the best technological choice, but it has many advantages in terms of simplicity, integration, and user device penetration.

Widespread device diffusion is undoubtedly one of the most important key success factors of the magic trio, HTML5, JavaScript, and CSS3. In fact, we can assert that almost every device with a modern web browser (PC, tablet, or smartphone) is able to access and deliver an HTML5 application to the user.

In other words, this is why we are here. There are millions of devices out there that allow end users to access our web applications, and we need to assure a reliable interaction for them. Think about home banking web sites. If you access your bank account, you won't feel very comfortable if a money transfer fails because of an application defect. Maybe because developers forgot a critical data validation or didn't properly handle a remote service error, you don't know if your transfer has been accepted or not.

Web applications are growing in complexity, not just because of modern web technologies, but also because of marketing strategies, product placements, or simple market competition. In this scenario, tightly related to the visibility and reputation of a company, we cannot approve a delivery plan that doesn't provide some kind of testing strategy.

Once we establish that testing is a pillar of our solution, we need to understand which is the best way to proceed in terms of software architecture and development. In this regard, it's very important to determine the very basic design principles that allow a proper approach to unit testing. In fact, even though HTML5 is a recent achievement, HTML and JavaScript are technologies that have been in use for quite some time.

The problem here is that many developers tend to approach modern web development in the same old way. This is a grave mistake because back in time, client-side JavaScript development was a underrated and mostly confined to simple UI graphic management.

Client-side development is historically driven by libraries such as Prototype, jQuery, and Dojo, whose primary feature is DOM (HTML Document Object Model or HTML markup) management. They can work in small web applications, but as soon as these grow in complexity, the codebase starts to become unmanageable and unmaintainable. We can't think that we can continue to develop JavaScript in the same way we did 10 years ago. In those days, we only had to apply some of the UI transformations dynamically. Today, we have to deliver full working applications.

We need a better design, but most of all we need to reconsider the client-side JavaScript development and apply the advanced design patterns and principles.

Coming back to the context of this book, a new development approach is essential if one of our objectives is a testable codebase. In fact, once we decide that we want to test our solution, we need to write testable code.

Does this sound silly? Well… not at all. We can't simply say that we want to test our code. We must ensure that it is possible. Not all code is testable.

Roy Osherove in his book, The Art of Unit Testing, gives the following definition:

Martin Fowler also writes about unit testing and the concept of isolation (http://martinfowler.com/bliki/UnitTest.html):

These definitions of unit testing talk about code that verifies other code isolating individual parts of a program. It's clear that we need to provide at least these basic characteristics to our code if we want to test it. In this book, we are going to suggest some useful design principles, but we won't focus on software development methodologies (for example, Extreme Programming, Waterfall, Agile, and others).

The World Wide Web is a fairly simple environment; all the content available is accessible using a web browser. Also, web browsers are conceptually simple applications. They ask for a web resource, a server sends that resource, and they display what's inside the received data. A web resource is nothing else than a series of files that represents different types of content:

Every browser supports these four types of content even if there are some interpretation differences (global standardization has not yet been reached).

We can say that JavaScript is the programming language of the Web, but its native DOM API is somewhat rudimentary. We have to write a lot of code to manage and transform HTML markup to bring the UI to life with some dynamic user interaction. Also, full standardization does not mean that the same code will work differently (or work at all) in different browsers.

Over the past few years, developers decided to resolve this situation; JavaScript libraries such as Prototype, jQuery, and Dojo have come to light.

jQuery is one of the most known open source JavaScript libraries, published in 2006 for the first time. Its huge success is mainly due to the following reasons:

Since its appearance, it has been used by thousands of developers as the foundation library. A large amount of JavaScript code all around the world has been built with jQuery in mind. A jQuery ecosystem grew up very quickly, and nowadays there are plenty of jQuery plugins that implement virtually everything related to web development.

A typical jQuery-based web application is something like the following sample page:

<!DOCTYPE html>
<html>
<head lang="en">
    <meta charset="UTF-8">
    <title>jQuery Sample</title>
    <style type="text/css">
        …
    </style>
</head>
<body>
    <h4>jQuery Sample</h4>
    <form id="inputForm">
        <label for="firstName">Name:&nbsp;</label>
        <br>
        <input type="text" id="firstName" name="firstName">
        <br>
        <label for="lastName">Last Name:&nbsp;</label>
        <br>
        <input type="text" id="lastName" name="lastName">
        <br>
        <fieldset>
            <legend>Nationality:</legend>
            <input type="radio" name="nat" value="it" checked>Italian
            <br>
            <input type="radio" name="nat" value="foreign">Foreign
            <br>
            <select id="foreignNat" disabled="disabled">
                <option value="">Select an item...</option>
                <option value="us">American</option>
                <option value="uk">British</option>
                <option value="fr">French</option>
                <option value="other">Other</option>
            </select>
        </fieldset>
        <input type="submit" value="Submit">
        <br>
        <p id="resultMessage"></p>c
    </form>
    <script type="text/JavaScript" src="//ajax.googleapis.com/ajax/libs/jquery/1.11.0/jquery.min.js"></script>
    <script type="text/JavaScript">
        //JavaScript Code
    </script>
</body>
</html>

This is a simple HTML page with a single form and bunch of inputs:

If we want to validate this form before submission, we can add the following code in the script tag:

function showMessage (message, isError) {
  jQuery("#resultMessage").text(message);
  if (isError) {
    jQuery("#resultMessage").css("color", "red");
  } else {
    jQuery("#resultMessage").css("color", "green");
  }
  jQuery("#resultMessage").css("visibility", "visible");
}
function hideMessage () {
  jQuery("#resultMessage").css("visibility", "hidden");
}

hideMessage();

jQuery(document).ready(function () {
  jQuery("#inputForm input:radio").on("click", function () {
    if (jQuery(this).val() === "it") {
      jQuery("#foreignNat option").removeAttr("selected");
      jQuery("#foreignNat").attr("disabled", "disabled");
    } else {
      jQuery("#foreignNat").removeAttr("disabled");
    }
  });
  jQuery("form").submit(function (e) {
    e.preventDefault();
    hideMessage();
    jQuery("#resultMessage").text("Please fill First Name");
    if (!jQuery("#firstName").val()) {
      showMessage("Please fill First Name", true);
      return;
    }
    if (!jQuery("#lastName").val()) {
      showMessage("Please fill Last Name", true);
      return;
    }
    if (!jQuery("input[name=nat]:checked").val()) {
      showMessage("Please select Nationality", true);
      return;
    }
    if ((jQuery("input[name=nat]:checked").val() === "foreign") &&
      (!jQuery("#foreignNat option:selected").val())){
      showMessage("Please select Foreign Nationality", true);
      return;
    }
    //form submission, for example with an AJAX call
    showMessage("Form submitted", false);
  });
});

The preceding code is a typical example of jQuery-style programming. Nearly every line contains a jQuery call, from pure tag content management to event handling. It works and is also a simple API to learn; an average developer becomes productive in a very short period of time.

In the preceding code, we defined two helper functions (showMessage and hideMessage) to show and hide the alert message. Then, when the page is fully loaded (jQuery(document).ready(…)), we defined two event handler functions: one for the radio button click (jQuery("#inputForm input:radio").on("click", …)) and the other for the form submission (jQuery("form").submit(…)).

In the first one, we activate or disable the drop-down menu, whether or not the Foreign radio option is checked:

In the second event handler function, we make some input validation and proceed with form submission only if all the inputs are properly filled, providing a specific status message.

The preceding example is a simple one: there are a few HTML tags, the UI logic is quite simple (just a message that appears/disappears and drop-down menu that activates/deactivates), and the validation is pretty straightforward.

Yet, despite its simplicity, all of the code that we just wrote is virtually untestable. There are two main reasons:

The real problem here is that everything passes through a jQuery reference, that is, a jQuery("something") call. This means that we always need a live reference of the HTML page, otherwise those calls fail, and this is also true for a unit test case. We can't think of testing a piece of user interface logic running an entire web application!

Consider a real-case scenario, not this super simple example of a complex e-commerce website, and we need to test a specific page. We need to reach this page first (maybe we also need to enter some user credentials because it's a private page), provide some input data, and then start our test case. Think of repeating this journey as many times as different input data combinations are possible, or try to automate this process in someway. A real nightmare!

Worse than this, you have to repeat the entire process if you simply change a single HTML tag ID and nothing else. The UI logic is unchanged, but we need to assure that no jQuery tag reference breaks if we change something in the HTML markup. This is really too much work to do. We will soon realize that we spend more time running unit tests than developing the application.

On the other hand, large jQuery applications tend to be monolithic because jQuery itself allows the callback function nesting very easily and doesn't really promote any particular design strategy. The result is often a spaghetti code.

jQuery is a good option if you want to develop a specific custom plugin. We will also continue to use this library for pure user interface effects and animations, but we need something different to maintain a large web application's logic.

In the previous section, you learned that a development approach based on jQuery is not a good idea for a large web application.

To move a step forward, we need to decide what's the best option in terms of testable code. The main topic here is the application design; in other words, how we can build our codebase following a general guideline with testability in mind.

In software engineering, there's nothing better than not reinventing the wheel; we can rely on a safe and reliable resource: design patterns. Wikipedia provides a good definition for the term design pattern (http://en.wikipedia.org/wiki/Software_design_pattern):

There are tons of specific design patterns, but we also need something related to the presentation layer because this is where a JavaScript web application belongs.

The most important aspect in terms of design and maintainability of a JavaScript web application is a clear separation between the user interface (basically, the HTML markup) and the presentation logic (the JavaScript code that turns a web page dynamic and responsive to user interaction). This is what you learned digging into a typical jQuery web application.

According to MSDN's patterns & practices, there are other important aspects involved in the presentation design patterns (http://msdn.microsoft.com/en-us/library/ff647343.aspx):

At this point, we need to identify an effective implementation of a presentation design pattern and use it in our web applications. In this regard, I have to admit that the JavaScript community has made an extraordinary job in the last two years. So far, there are tons of frameworks and libraries that implement a particular presentation design pattern.

We only need to choose which framework fits our needs, for example, we can start by taking a look at the MyTodo MVC website (http://todomvc.com/). This is an open source project that shows how to build the same web application using a different library each time.

In this book, we will use Knockout.JS, one of the most popular libraries that implements the Model-View-ViewModel design pattern.

Most of these libraries implement a so-called MV* design pattern (Knockout.JS does this too). MV* means that every design pattern belongs to a broader family with a common root, which is Model-View-Controller. The MVC pattern is one of the oldest and most enduring architectural design patterns. Originally designed by Trygve Reenskaug, working on Smalltalk-80 back in 1979, it has been heavily refactored since then.

Basically, the MVC pattern enforces the isolation of business data (Models) from user interfaces (Views), with a third component (Controllers) managing the logic and user input. It can be described as (Addy Osmani, Learning JavaScript Design Patterns, http://addyosmani.com/resources/essentialjsdesignpatterns/book/#detailmvc):

This general definition has slightly changed over the years, not only to adapt its implementation to different technologies and programming languages, but also because changes have been made to the Controller part. Model-View-Presenter and Model-View-ViewModel are the most well known alternatives to the MVC pattern.

The MV* presentation design patterns are a valid answer to our need; an architectural design guideline that promotes separation of concerns and isolation, the two most important factors needed for software testing. In this way, we can test the models, views, and third actor whatever it is (a Controller, Presenter, ViewModel, and so on) separately.

On the other hand, adopting a presentation design pattern doesn't mean that we cease to use jQuery. jQuery is a great library and we will continue to add its reference to our pages, but we will also integrate its use wisely in a better design context.

This chapter gives a significant vision about software testing in the contemporary web era, starting with the most important consideration; it's unimaginable to think of a web application that is not supported by a solid testing strategy.

You learned that modern web development can't follow the same old paradigms such as using the well known jQuery library as the application cornerstone. Complex web applications tend to become unmanageable and untestable without a good architectural design. Every framework or library should be used in the correct context. jQuery has advantages in developing a plugin and pure user interface customizations, but it's not the best option if adopted as an application logic framework.

We finally saw that if we want to satisfy both maintainability and testability, we need to adopt a presentation design pattern. In the JavaScript community, the emerging presentation frameworks and libraries are a part of the MV* family and they promote separation of concerns and isolation between their components. In particular, Knockout.JS is one of the most well-known libraries and implements a specific pattern variation, which is Model-View-ViewModel.

In the next chapter, you will learn more about Knockout.JS and its features.