Testing JavaScript browser code has been notoriously considered hard, and although there are many complications while dealing with cross-browser testing, the most common problem is not with the testing process but rather that the application code itself is not testable.

Since every element in the browser's document is accessible globally, it is easy to write a monolithic piece of JavaScript code, which deals with the whole page. This leads to a number of problems, and the biggest one is that it is pretty hard to test.

In this chapter, we are going to get the best practices on how to write maintainable and testable browser code.

To implement the user interface, we are going to use jQuery, a well-known JavaScript library that abstracts the browser's DOM in a clean and simple API that works across different browsers.

To make the writing of the specs easier, we're going to use Jasmine jQuery, a Jasmine extension that adds new matchers to perform assertions on jQuery objects. To install it and its jQuery dependency, download the following files:

Save these files as jasmine-jquery.js and jquery.js respectively inside the lib folder, and add them to SpecRunner.html, as follows:

<script src="lib/jquery.js"></script>
<script src="lib/jasmine-jquery.js"></script>

As seen until now, we have already created separate abstractions to handle both an investment and its associated stock. Now, it is time to develop this application's user interface and achieve a good result, which is all a matter of organization and good practices.

The same principles of software engineering that we apply on the server-side code must not be left behind when writing frontend JavaScript code. It is still important to think about components and proper separation of concerns.

Thinking in terms of components (Views)

We've talked about the monolithic JavaScript code bases that plague most of the Web, which that are code bases that are impossible to test. And the best way not to fall into this trap is by coding the application driven by tests.

Consider the mockup interface of our Investment Tracker application:

This shows the Investment Tracker application's mockup interface

How would we go about implementing it? It is easy to see that this application has two different responsibilities:

• One responsibility is to add an investment
• Another responsibility is to list the added investments

So, we could start by breaking this interface into two different components. To better describe them, we are going to borrow a concept from MVC frameworks, such as Backbone.js, and call them Views.

So, here it is, at the top level of the interface, with two base components:

• NewInvestmentView: This will be responsible for creating new investments
• InvestmentListView: This is going to be a list of all added investments