Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases now! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
WEB APP TESTING USING KNOCKOUT.JS
WEB APP TESTING USING KNOCKOUT.JS

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

Arrow left icon
Profile Icon Roberto Messora
Arrow right icon
Free Trial
Full star icon Full star icon Full star icon Full star icon Full star icon 5 (3 Ratings)
Paperback Nov 2014 154 pages 1st Edition
eBook
NZ$26.99 NZ$38.99
Paperback
NZ$48.99
Subscription
Free Trial
Arrow left icon
Profile Icon Roberto Messora
Arrow right icon
Free Trial
Full star icon Full star icon Full star icon Full star icon Full star icon 5 (3 Ratings)
Paperback Nov 2014 154 pages 1st Edition
eBook
NZ$26.99 NZ$38.99
Paperback
NZ$48.99
Subscription
Free Trial
eBook
NZ$26.99 NZ$38.99
Paperback
NZ$48.99
Subscription
Free Trial

What do you get with a Packt Subscription?

Free for first 7 days. $19.99 p/m after that. Cancel any time!
Product feature icon Unlimited ad-free access to the largest independent learning library in tech. Access this title and thousands more!
Product feature icon 50+ new titles added per month, including many first-to-market concepts and exclusive early access to books as they are being written.
Product feature icon Innovative learning tools, including AI book assistants, code context explainers, and text-to-speech.
Product feature icon Thousands of reference materials covering every tech concept you need to stay up to date.
Subscribe now
View plans & pricing
Table of content icon View table of contents Preview book icon Preview Book

WEB APP TESTING USING KNOCKOUT.JS

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 (http://martinfowler.com/bliki/UnitTest.html):

"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>
<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>

Tip

Downloading the example code

You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support 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:

Escaping from the jQuery-style development

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:

Escaping from the jQuery-style development

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.

Escaping from the jQuery-style development

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 (http://en.wikipedia.org/wiki/Software_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 (http://msdn.microsoft.com/en-us/library/ff647343.aspx):

  • 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 (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):

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

Summary

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

Description

If you are a JavaScript developer, beginner, or an expert who wants to improve quality standards in terms of solutions design and functional verification, this book is for you. Basic understanding of web development, HTML, and JavaScript is required.

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, Length, Edition, Language, ISBN-13
Publication date : Nov 17, 2014
Length: 154 pages
Edition : 1st
Language : English
ISBN-13 : 9781783982844
Vendor :
Netscape
Languages :
Tools :

What do you get with a Packt Subscription?

Free for first 7 days. $19.99 p/m after that. Cancel any time!
Product feature icon Unlimited ad-free access to the largest independent learning library in tech. Access this title and thousands more!
Product feature icon 50+ new titles added per month, including many first-to-market concepts and exclusive early access to books as they are being written.
Product feature icon Innovative learning tools, including AI book assistants, code context explainers, and text-to-speech.
Product feature icon Thousands of reference materials covering every tech concept you need to stay up to date.
Subscribe now
View plans & pricing

Product Details

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

Packt Subscriptions

See our plans and pricing
Modal Close icon
$19.99 billed monthly
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Simple pricing, no contract
$199.99 billed annually
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just NZ$7 each
Feature tick icon Exclusive print discounts
$279.99 billed in 18 months
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just NZ$7 each
Feature tick icon Exclusive print discounts

Frequently bought together


Stars icon
Total NZ$ 178.97
KnockoutJS Web Development
NZ$48.99
MASTERING KNOCKOUTJS
NZ$80.99
WEB APP TESTING USING KNOCKOUT.JS
NZ$48.99
Total NZ$ 178.97 Stars icon

Table of Contents

5 Chapters
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

Rating distribution
Full star icon Full star icon Full star icon Full star icon Full star icon 5
(3 Ratings)
5 star 100%
4 star 0%
3 star 0%
2 star 0%
1 star 0%
Scott Addie Dec 13, 2014
Full star icon Full star icon Full star icon Full star icon Full star icon 5
Messora does a fantastic job of reviewing basics of the MVVM development pattern. As a seasoned JavaScript developer who’s used Knockout on a daily basis for a few years and is interested in developing highly testable Single Page Applications (SPAs), this book was of great value. Best practices are clearly identified, and a thorough explanation is provided for each. Ever wondered how to adopt separation of concerns in the JavaScript world to avoid spaghetti code and why it’s a good idea to avoid using jQuery as the cornerstone of your web application? Ever wondered when to choose BDD over TDD to satisfy your testing needs? The answers are found within.Third party libraries such as Jasmine, Gulp, Karma, Phantom, and Postal are introduced. Coming from a Mocha and Grunt background myself, it was worthwhile to see the differences in Jasmine and Gulp, respectively. If you’re just getting started with Jasmine or if you want a refresher course on writing testable JavaScript, consider this book. It’s also a good read for those coming from a jQuery background who are beginning to explore the plethora of MV* frameworks/libraries out there.
Amazon Verified review Amazon
Adam Rackis Dec 15, 2014
Full star icon Full star icon Full star icon Full star icon Full star icon 5
The author does a great job of diving into the MVVM pattern, Knockout.js, as well as a host of technologies and frameworks that can be used to create automated tests for a single page application, including Gulp, postal.js and Jasmine. The writing is crisp and clear, and the book as a whole was a joy to read. Highly recommend.
Amazon Verified review Amazon
Robert Gaut Feb 06, 2015
Full star icon Full star icon Full star icon Full star icon Full star icon 5
I was very pleased to serve as a reviewer on this book. The book is very well-written and is packed with a ton of useful information and practical techniques. The Knockout.JS sections are very clear and approachable to beginners and advanced developers alike. The book especially shines when it comes to unit testing Web apps using Jasmine and the sections on Node.JS, Gulp.JS, Karma, and Phantom.JS are equally impressive. Using the libraries and techniques described in this book have definitely improved my daily development workflows. I highly recommend this book!
Amazon Verified review Amazon
Get free access to Packt library with over 7500+ books and video courses for 7 days!
Start Free Trial

FAQs

What is included in a Packt subscription? Chevron down icon Chevron up icon

A subscription provides you with full access to view all Packt and licnesed content online, this includes exclusive access to Early Access titles. Depending on the tier chosen you can also earn credits and discounts to use for owning content

How can I cancel my subscription? Chevron down icon Chevron up icon

To cancel your subscription with us simply go to the account page - found in the top right of the page or at https://subscription.packtpub.com/my-account/subscription - From here you will see the ‘cancel subscription’ button in the grey box with your subscription information in.

What are credits? Chevron down icon Chevron up icon

Credits can be earned from reading 40 section of any title within the payment cycle - a month starting from the day of subscription payment. You also earn a Credit every month if you subscribe to our annual or 18 month plans. Credits can be used to buy books DRM free, the same way that you would pay for a book. Your credits can be found in the subscription homepage - subscription.packtpub.com - clicking on ‘the my’ library dropdown and selecting ‘credits’.

What happens if an Early Access Course is cancelled? Chevron down icon Chevron up icon

Projects are rarely cancelled, but sometimes it's unavoidable. If an Early Access course is cancelled or excessively delayed, you can exchange your purchase for another course. For further details, please contact us here.

Where can I send feedback about an Early Access title? Chevron down icon Chevron up icon

If you have any feedback about the product you're reading, or Early Access in general, then please fill out a contact form here and we'll make sure the feedback gets to the right team. 

Can I download the code files for Early Access titles? Chevron down icon Chevron up icon

We try to ensure that all books in Early Access have code available to use, download, and fork on GitHub. This helps us be more agile in the development of the book, and helps keep the often changing code base of new versions and new technologies as up to date as possible. Unfortunately, however, there will be rare cases when it is not possible for us to have downloadable code samples available until publication.

When we publish the book, the code files will also be available to download from the Packt website.

How accurate is the publication date? Chevron down icon Chevron up icon

The publication date is as accurate as we can be at any point in the project. Unfortunately, delays can happen. Often those delays are out of our control, such as changes to the technology code base or delays in the tech release. We do our best to give you an accurate estimate of the publication date at any given time, and as more chapters are delivered, the more accurate the delivery date will become.

How will I know when new chapters are ready? Chevron down icon Chevron up icon

We'll let you know every time there has been an update to a course that you've bought in Early Access. You'll get an email to let you know there has been a new chapter, or a change to a previous chapter. The new chapters are automatically added to your account, so you can also check back there any time you're ready and download or read them online.

I am a Packt subscriber, do I get Early Access? Chevron down icon Chevron up icon

Yes, all Early Access content is fully available through your subscription. You will need to have a paid for or active trial subscription in order to access all titles.

How is Early Access delivered? Chevron down icon Chevron up icon

Early Access is currently only available as a PDF or through our online reader. As we make changes or add new chapters, the files in your Packt account will be updated so you can download them again or view them online immediately.

How do I buy Early Access content? Chevron down icon Chevron up icon

Early Access is a way of us getting our content to you quicker, but the method of buying the Early Access course is still the same. Just find the course you want to buy, go through the check-out steps, and you’ll get a confirmation email from us with information and a link to the relevant Early Access courses.

What is Early Access? Chevron down icon Chevron up icon

Keeping up to date with the latest technology is difficult; new versions, new frameworks, new techniques. This feature gives you a head-start to our content, as it's being created. With Early Access you'll receive each chapter as it's written, and get regular updates throughout the product's development, as well as the final course as soon as it's ready.We created Early Access as a means of giving you the information you need, as soon as it's available. As we go through the process of developing a course, 99% of it can be ready but we can't publish until that last 1% falls in to place. Early Access helps to unlock the potential of our content early, to help you start your learning when you need it most. You not only get access to every chapter as it's delivered, edited, and updated, but you'll also get the finalized, DRM-free product to download in any format you want when it's published. As a member of Packt, you'll also be eligible for our exclusive offers, including a free course every day, and discounts on new and popular titles.