Setting up Testing

Published on Mar 20, 2014


Update: This screencast is OUTDATED. More testing videos coming soon!




Automated testing is an idea that's been around for awhile, but it's just now making its way through the JavaScript world. That's because it's only recently that we've been writing significant amounts of code in JavaScript, so there's a need for testing, but unlike in many other software ecosystems, there's no standard way to do it. Check out this list of JavaScript unit testing tools. This is just 1 answer of many to this question. That list is mostly test runners and doesn't get into assertion libraries, integration testing tools, or any of the other things that you'll need to run a full test sweep. Of the 3 test specific tools that we're going to be using in this screencast, it lists only 1 of them. While the JavaScript testing world is highly fragmented there is a testing stack that works really well for us at the front side. I'm going to show you how to duplicate it.

Our set up is to use npm and Bower to manage to manage our dependencies, Karma is our test runner, Mocha is our test framework, and Chai is our assertion library. First check to make sure that you have npm installed, npm is the Node Package Manager, which helps you download and use packages on your system. Installing it isn't hard but it defers slightly between Mac, Windows, and Linux. In the show notes I've linked to a guide that will help you get it installed. We can download packages individually by typing npm install, then the package name. Let's try it with Bower, we'll go ahead and use the -g tag, that means it's installed globally and we can access it from anywhere in the command line.

You'll notice that it installed Bower and all it's dependencies. This method of doing things is fine if you're guaranteed to only run this code from one machine, most people eventually want to share, whether that's with other people or with a production server. You'll end up keeping a list of packages that everyone has to install before they can use the code, so why not just keep the list in a file and have the computer run it? We do that in package.json. Package.json is a json hash, which in our case includes only a hash of dependencies. Our dependencies are Bower, Karma, Karma Mocha, Karma Chai, and Karma Sinon Chai. The stars here mean that we can use any version of the library, so we'll try to get the latest, however, we've locked Karma Sinon Chai down to the 0.1.4 version. Typing npm install into the command line, it installs all of them into the node modules folder, right here.

Bower is another JavaScript package manager, the niche it seems to serve is in managing the files that you would normally package with your front end code. We're going to use it to include Ember and associated packages in our tests. We'll create a Bower.json file, similar to our package.json. You'll see that in this case we're specifying version numbers for most of our packages. We also have to include a name, although I'm not sure why we have to do that. Now when we run Bower install, it will install those packages and their dependencies into the Bower components folder. At this point it's a good idea to add the node modules and Bower components folders to your .gitignore file, if you don't your git commits will be cluttered with changes within your libraries.

Now we need to set up our test runner, Karma. When you run Karma init in the console you'll be prompted to answer several questions. We're going to say Mocha as a test framework, no to require JS, Chrome Canary for the browser, blank for the code sources, because we'll putting them in by hand later, blank for the exclusions because you don't need any, and yes for autowatch. Now we'll edit our karma.conf file, we'll start by adding the Sign On Chai framework, which is needed to run Chai within our tests. Then we'll manually tell Karma which files to load, we'll load in the Bower files, being sure to specify the correct file in the folder. That's usually has the same name as the library or it's called something like main.js. Then we'll load in the application both app.js and index.html, finally we have our test runner and test framework set up.

Now we need to actually get a test running, we'll create a file called example-spec.js, then within the example spec we'll make a very simple test. I will explain the functionality of what's happening in here next time. The gist of it is that we're testing that 1 plus 1 is equal to 2. That's testing that our testing framework is working well. We're going to test if this actually works. We're going to call Karma start and specify that file that we've used to define all this. Uh, oh, looks like we have a problem . It appears that we did not include our test file, so let's do that, and restart our test runner. It works.

This process only takes about 15 minutes to set up, but it is a bit of a tangle, hopefully Ember CLI and Broccoli will make the complications of this screencast obsolete very soon. The good news for now is that everyone in your team can just use NPM install, and Bower install, and be ready to go. It takes the first person 15 minutes to set it up, but after that it's just a few commands away. Next week we'll do some real tests in Ember, until then, happy coding.