Testing Clientside JavaScript

Testing Clientside JavaScript is the final course in the JavaScript Learning Path on Pluralsight.

This is the longest of all these courses; almost 5 hours in total. If you are new to unit testing in JavaScript then I recommend watching the entire course, but if you are only interested in learning a particular framework you can just watch that one module.

I am a Visual Studio user and work with C# as much if not more than JavaScript. I like to run all my C# and JavaScripts together at the same time so I use ReSharper to run them for me. ReSharper supports QUnit and Jasmine.

This course is 3 years old now so some of the details have since changed, but all of the basic concepts described in this course remain just the same.


Joe explains that QUnit writes TDD style tests that look a lot like unit tests in NUnit and similar server side frameworks.

It supports asynchronous tests, and integrates with Continuous Integration.


Jasmine uses BDD style tests. Joe explains Jasmine custom matchers.

Jasmine also supports asynchronous tests, and Joe covers the jasmine.async library which makes this easier.

Jasmine has a good introductory guide at jasmine.github.io


Mocha is highly versatile. It supports both TDD and BDD styles tests and you can configure it however you want.

Mocha requires you to find your own preferred assertion library to work with it. The most popular one is Chai JS.


This module looks at the reasons for using Mocks, which include Isolation, easy flow control, and testing interactions.

Joe explains the difference between a dummy, a fake, a stub, a spy and a mock

Jasmine Spies

This module looks at the SpyOn() function, and then the createSpyObj() function.

Joe also explains using custom matchers for making assertions about spies


This is the longest module in the course, and is over an hour long.

Sinon is a sophisticated mocking library allowing you to use spies, stubs and mocking.

Joe explains the matchers and  mock timers, and then Sinon’s mock XHR functionality: both useFakeXMLHttpRequest for high control and fakeServer – a higher level interface for defining canned responses.

Joe wraps up with Sandboxing, which restores any  global objects modified by tests back to their original state.

Testing Utilities

This covers three main tools: Live Reload, Karma, and Grunt.

Whenever I’m working outside of Visual Studio, I use the Karma for running my JavaScript tests, and happily second Joe’s recommendation here.

For build tools, there are a number of alternatives options available today. Grunt is still a good tool and worth considering, however so is Gulp, Browserify and Webpack.

For a more in depth look at Grunt, watch Introduction to Grunt by Derik Whittaker.

If you are interested in Gulp, watch JavaScript Build Automation With Gulp.js by John Papa

If you want to learn more about Browserify, see Creating JavaScript Modules with Browserify by Jeff Valore

Finally, if you WebPack is what you want to learn, see Webpack Fundamentals by Joe Eames

If you don’t know which build tool you should learn, you can find more information from Cory House: Browserify vs Webpack

I hope all of this helps. Please add a comment below to let me know if this was helpful, or to ask any questions.


3 thoughts on “Testing Clientside JavaScript

  1. Pingback: Zombie Code Kill

  2. Pingback: Learning Unit Testing and Test Driven Development | Zombie Code Kill

  3. Pingback: RequireJS: JavaScript Dependency Injection and Module Loading | Zombie Code Kill

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s