Search icon CANCEL
Cart icon
Close icon
You have no products in your basket yet
Save more on your purchases!
Savings automatically calculated. No voucher code required
Arrow left icon
All Products
Best Sellers
New Releases
Learning Hub
Free Learning
Arrow right icon

WEB APP TESTING USING KNOCKOUT.JS: Design, implement, and maintain a fully tested JavaScript web application using Knockout.JS

By Roberto Messora
€19.99 €13.98
Book Nov 2014 154 pages 1st Edition
€19.99 €13.98
€14.99 Monthly
€19.99 €13.98
€14.99 Monthly

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Buy Now
Table of content icon View table of contents Preview book icon Preview Book


Chapter 1. Web Application Testing in the Modern Web

Every software development book tries to explain some important technical aspects of a particular framework, technology, or methodology. This book is not different from this approach, but I'd like that everyone reading these chapters will try not only to think of the technicalities, but also to keep in mind the big picture.

Yes, I'd like it very much that we, that is everyone involved in software development, really start to think about the broader scenario, at least in general terms, as the most important objective of our work.

Every technique we learn, every methodology, analysis, and nonfunctional requirement, should be treated and chosen as a brick to build a comfortable house, for a variety of reasons. Concepts such as the end users, stakeholders, project economics, and so on should be handled as primary elements when deciding to adopt a particular technology.

Throughout this book, you will learn something very important in delivering modern web applications; I hope all of these notions will be used to improve web development awareness and understanding, not personal delight.

In this chapter, you will learn:

  • Why software testing should be an essential habit

  • Why the classic jQuery-style development is not the best choice, unless you are developing a general purpose plugin

  • Why we should consider presentation design patterns as the cornerstone of the client-side web development

Software testing

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:

  • Works as expected

  • Meets functional and nonfunctional requirements

  • Is free of defects

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:

  • The right testing levels (unit, integration, acceptance, and so on)

  • The right testing types (regression, acceptance, usability, security, and so on)

  • The right testing process (test first, waterfall, top-down, and so on)

  • The right testing tools (frameworks, third-party products, dedicated environments, and so on)

  • The right testing outputs/reports, depending on who will evaluate them

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:

  • Better design

  • To avoid regression errors

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 modern Web

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:

"A unit test is a piece of a code (usually a method) that invokes another piece of code and checks the correctness of some assumptions afterward. If the assumptions turn out to be wrong, the unit test has failed. A unit is a method or function."

Martin Fowler also writes about unit testing and the concept of isolation (

"A more important distinction is whether the unit you're testing should be isolated from its collaborators. Imagine you're testing an order class's price method. The price method needs to invoke some functions on the product and customer classes. If you follow the principle of collaborator isolation you don't want to use the real product or customer classes here, because a fault in the customer class would cause the order class's tests to fail. Instead you use TestDoubles for the collaborators."

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).

Escaping from the jQuery-style development

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:

  • User interface structures: HTML markup

  • User interface graphic styles: CSS

  • User interface programs and executables: JavaScript

  • Data: JSON or XML

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:

  • A simple and detailed API that allows us to manage HTML DOM elements

  • Cross-browser support

  • Simple and effective extensibility

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>
<head lang="en">
    <meta charset="UTF-8">
    <title>jQuery Sample</title>
    <style type="text/css">
    <h4>jQuery Sample</h4>
    <form id="inputForm">
        <label for="firstName">Name:&nbsp;</label>
        <input type="text" id="firstName" name="firstName">
        <label for="lastName">Last Name:&nbsp;</label>
        <input type="text" id="lastName" name="lastName">
            <input type="radio" name="nat" value="it" checked>Italian
            <input type="radio" name="nat" value="foreign">Foreign
            <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>
        <input type="submit" value="Submit">
        <p id="resultMessage"></p>c
    <script type="text/JavaScript" src="//"></script>
    <script type="text/JavaScript">
        //JavaScript Code


Downloading the example code

You can download the example code files for all Packt books you have purchased from your account at If you purchased this book elsewhere, you can visit and register to have the files e-mailed directly to you.

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) {
  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");


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("form").submit(function (e) {
    jQuery("#resultMessage").text("Please fill First Name");
    if (!jQuery("#firstName").val()) {
      showMessage("Please fill First Name", true);
    if (!jQuery("#lastName").val()) {
      showMessage("Please fill Last Name", true);
    if (!jQuery("input[name=nat]:checked").val()) {
      showMessage("Please select Nationality", true);
    if ((jQuery("input[name=nat]:checked").val() === "foreign") &&
      (!jQuery("#foreignNat option:selected").val())){
      showMessage("Please select Foreign Nationality", true);
    //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:

  • User interface items are tightly coupled with the user interface logic

  • The user interface logic spans inside the event handler callback functions

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.

Presentation design patterns

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 (

"In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design.

A design pattern is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations.

Patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system."

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 (

  • Document simple mechanisms that work

  • Provide a common vocabulary and taxonomy for developers and architects

  • Enable solutions to be described concisely as combinations of patterns

  • Enable the reuse of architecture, design, and implementation decisions

  • You have to support user interactions of increasing complexity, involving complex relationships between forms and pages in the user interface

  • Existing business processes change and you have to present new or modified functionalities to your users

  • You have to port your application to other platforms or make the application accessible to additional client types (such as mobile devices)

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 ( 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,

  • A Model representing domain-specific data and ignorant of the user interface (Views and Controllers). When a model is changed, it will inform its observers.

  • A View representing the current state of a Model. The Observer pattern was used to let the View know whenever the Model was updated or modified.

  • Presentation was taken care of by the View, but there wasn't just a single View and Controller—a View-Controller pair was required for each section or element being displayed on the screen.

  • The Controller's role in this pair handles user interaction (such as key-presses and actions, for example, clicks), making decisions for the View.

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.

Left arrow icon Right arrow icon

Key benefits

What you will learn

Introduce and use Knockout.JS in a JavaScript web application as a presentation framework Design a JavaScript web application using the wellknown ModelViewViewModel presentation pattern Set up a simple testing environment with Jasmine Unit test a JavaScript web application using the Behavior Driven Development approach Adopt the correct development strategies to obtain the best results in terms of unit testing Install and set up an automated testing environment using Node.JS and Karma Execute unit testing and code coverage on development and minified production code

Product Details

Country selected

Publication date : Nov 17, 2014
Length 154 pages
Edition : 1st Edition
Language : English
ISBN-13 : 9781783982844
Vendor :
Category :

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Buy Now

Product Details

Publication date : Nov 17, 2014
Length 154 pages
Edition : 1st Edition
Language : English
ISBN-13 : 9781783982844
Vendor :
Category :

Table of Contents

11 Chapters
Web App Testing Using Knockout.JS Chevron down icon Chevron up icon
Credits Chevron down icon Chevron up icon
About the Author Chevron down icon Chevron up icon
About the Reviewers Chevron down icon Chevron up icon Chevron down icon Chevron up icon
Preface Chevron down icon Chevron up icon
1. Web Application Testing in the Modern Web Chevron down icon Chevron up icon
2. The Knockout.JS UI Framework Explained Chevron down icon Chevron up icon
3. The Jasmine Unit Testing Framework Explained Chevron down icon Chevron up icon
4. Unit Testing Strategies Chevron down icon Chevron up icon
5. Setting Up an Effective Testing Environment Chevron down icon Chevron up icon

Customer reviews

Top Reviews
Rating distribution
Empty star icon Empty star icon Empty star icon Empty star icon Empty star icon 0
(0 Ratings)
5 star 0%
4 star 0%
3 star 0%
2 star 0%
1 star 0%
Top Reviews
No reviews found
Get free access to Packt library with over 7500+ books and video courses for 7 days!
Start Free Trial


How do I buy and download an eBook? Chevron down icon Chevron up icon

Where there is an eBook version of a title available, you can buy it from the book details for that title. Add either the standalone eBook or the eBook and print book bundle to your shopping cart. Your eBook will show in your cart as a product on its own. After completing checkout and payment in the normal way, you will receive your receipt on the screen containing a link to a personalised PDF download file. This link will remain active for 30 days. You can download backup copies of the file by logging in to your account at any time.

If you already have Adobe reader installed, then clicking on the link will download and open the PDF file directly. If you don't, then save the PDF file on your machine and download the Reader to view it.

Please Note: Packt eBooks are non-returnable and non-refundable.

Packt eBook and Licensing When you buy an eBook from Packt Publishing, completing your purchase means you accept the terms of our licence agreement. Please read the full text of the agreement. In it we have tried to balance the need for the ebook to be usable for you the reader with our needs to protect the rights of us as Publishers and of our authors. In summary, the agreement says:

  • You may make copies of your eBook for your own use onto any machine
  • You may not pass copies of the eBook on to anyone else
How can I make a purchase on your website? Chevron down icon Chevron up icon

If you want to purchase a video course, eBook or Bundle (Print+eBook) please follow below steps:

  1. Register on our website using your email address and the password.
  2. Search for the title by name or ISBN using the search option.
  3. Select the title you want to purchase.
  4. Choose the format you wish to purchase the title in; if you order the Print Book, you get a free eBook copy of the same title. 
  5. Proceed with the checkout process (payment to be made using Credit Card, Debit Cart, or PayPal)
Where can I access support around an eBook? Chevron down icon Chevron up icon
  • If you experience a problem with using or installing Adobe Reader, the contact Adobe directly.
  • To view the errata for the book, see and view the pages for the title you have.
  • To view your account details or to download a new copy of the book go to
  • To contact us directly if a problem is not resolved, use
What eBook formats do Packt support? Chevron down icon Chevron up icon

Our eBooks are currently available in a variety of formats such as PDF and ePubs. In the future, this may well change with trends and development in technology, but please note that our PDFs are not Adobe eBook Reader format, which has greater restrictions on security.

You will need to use Adobe Reader v9 or later in order to read Packt's PDF eBooks.

What are the benefits of eBooks? Chevron down icon Chevron up icon
  • You can get the information you need immediately
  • You can easily take them with you on a laptop
  • You can download them an unlimited number of times
  • You can print them out
  • They are copy-paste enabled
  • They are searchable
  • There is no password protection
  • They are lower price than print
  • They save resources and space
What is an eBook? Chevron down icon Chevron up icon

Packt eBooks are a complete electronic version of the print edition, available in PDF and ePub formats. Every piece of content down to the page numbering is the same. Because we save the costs of printing and shipping the book to you, we are able to offer eBooks at a lower cost than print editions.

When you have purchased an eBook, simply login to your account and click on the link in Your Download Area. We recommend you saving the file to your hard drive before opening it.

For optimal viewing of our eBooks, we recommend you download and install the free Adobe Reader version 9.