JavaScript for Line of Business Applications

This post will explain the tools needed to overcome the challenges of testing with Node.js. Together, they form an essential testing suite that will cover almost any project. The setup isn’t the most complex or feature-rich, but you could say that’s on purpose. If that sounds counter-intuitive… read on.

• A Testing Framework (Mocha, Vows, Intern)
• An Assertion Library (Chai, Assert)
• Stubs (Sinon)
• Module Control (Mockery, Rewire)

For the 4 past months, I've been working for Mozilla on some big project where such testing strategy was involved. While I wish we could use CasperJSin this perspective, Firefox wasn't supported at the time and we needed to ensure proper compatibility with its JavaScript engine. So we went with usingMocha, Chai and Sinon and they have proven to be a great workflow for us so far.

Mocha is a test framework while Chai is an expectation one. Let's say Mocha setups and describes test suites and Chai provides convenient helpers to perform all kinds of assertions against your JavaScript code.

As a team with a strong taste for automated testing we focused from the beginning on how to test our Angular app. In this post we want to describe our different types of tests and how they form a Test Pyramid.

Level 4: Selenium Tests.
Level 3: E2E (Scenario) Tests.
Level 2: Directive Tests.
Level 1: Unit Tests.

For each kind of test, we will explain the following aspects:

* Purpose: What’s the idea behind this type of tests. When to use and what is being tested (the scope of the test). Principles how to write the test.
* Implementation: How does it look like in source code. Examples, technical issues.
* Our experience: Reflection about our specific experience. Some heuristic data.

If you are developing for the web – apps or websites, then it is almost impossible to escape JavaScript. At some point, you will write some client-side code and as the application grows and the requirements become more complex, your JavaScript code is bound to grow with it. Like with every other complex piece of code, we need to be confident that the code behaves as expected. It doesn’t matter if you decide to use TDD or not, what’s important is to test your code. You can do this manually, very tedious and error prone, or programmatically. The choice is yours!

JavaScript is a different beast on its own, especially if you, like me, are used to doing server-side programming and testing. So how does one start with client-side unit tests?

Our unit tests are organized into suites. Each suite consists of a number of files, each of which tests a single AMD module. Most of the modules under test when I started down this path were pretty isolated – they didn’t have a ton of dependencies generally, and had very few runtime dependencies. They didn’t interact with other modules that much. Almost all of the existing unit test files loaded a module, executed its methods, and inspected the return value. No big deal.

Feature-related code – especially already-written feature-related code – is a different story. Views have templates. Models expect data. Models pass information to views, and views pass information to models. Some models need parents; others expect children. And pretty much everything depended on a global-ish message broker to pass information around.

One of my favorite parts of Ember is how easy it is to test. The framework comes bundled with a system testing framework, and its object model makes unit testing a breeze. Combine all that with a great test runner that has CI integration, and you have a really awesome testing ecosystem for your new app.

This framework allows you to make high-level assertions regarding your applications’ state, mostly by querying and interacting with the DOM through JQuery in a black box fashion. Since the tests are pure JavaScript however, we also get direct access to our running application if needed for testing.

The framework comes bundles with a few simple helpers to do common operations such as clicking a button, filling in a text field, or querying for the presence of a certain DOM element. A typical system test using ember-testing might look like this...

AngularJS has a great testing story - it’s all based on Dependency Injection, the Karma test runner was written by one of its core developers Vojta Jina and it ships with a variety of mocks like the $httpBackend for unit testing requests to remote services.

What I haven’t been able to find much of are examples showing how to take advantage of these features when testing an application that does more than just expose objects connected via a rest api.

Today we’re going to build a simple Tic-Tac-Toe game writing unit tests along the way.