Testing Clientside JavaScript

Learn the tools and techniques to write comprehensive unit tests for your clientside JavaScript code.
Course info
Rating
(494)
Level
Intermediate
Updated
Feb 12, 2013
Duration
4h 50m
Table of contents
Description
Course info
Rating
(494)
Level
Intermediate
Updated
Feb 12, 2013
Duration
4h 50m
Description

Javascript is the programming language of the web, and more and more developers are using it every day. Unfortunately, far less JavaScript code is tested than just about any other kind of code. This course will teach you the tools and techniques necessary to enable you to write unit tests for your browser-based JavaScript code. First you will learn the three most popular JavaScript unit testing frameworks: QUnit, Jasmine, and Mocha. Then you will learn how to do mocking in JavaScript, and finally you will learn some additional utility tools that will make writing tests and getting results a breeze.

About the author
About the author

Joe has been a web developer for the last 13 of his 16+ years as a professional developer. He has specialized in front end and middle tier development . Although his greatest love is writing code, he also enjoys teaching and speaking about code.

More from the author
Unit Testing in Angular
Beginner
3h 20m
22 May 2018
Angular: The Big Picture
Beginner
1h 7m
13 Dec 2017
More courses by Joe Eames
Section Introduction Transcripts
Section Introduction Transcripts

Mocha
Hello. This is Pluralsight's course on testing client side JavaScript. In this module we will be discussing the mocha unit testing framework. This is our third and final module on unit testing frameworks. We're going to start with an introduction to mocha. Then we're going to talk about installing and setting it up. Then we're going to discuss assertion libraries which are third party libraries which let you choose from a variety of different styles of assertions in your tests. After that, we'll cover writing and running tests in mocha, and then how mocha handles an asynchronous test. And we'll finish up with a discussion on using mocha with a continuous integration server. Mocha is a very interesting library. It is possibly the most versatile JavaScript testing framework. It is open source and hosted on GitHub. It was primarily developed for node, but has gained widespread adoption for browser testing. Mocha supports both client side and server side testing, and it supports both BDD and TDD style tests. It can be run both from the browser and on the command line, although it requires node if you wish to run it on the command line. Mocha supports any assertion library. We'll discuss exactly what that means in the assertion library section of this module. Mocha also supports async testing right out of the box. The mocha implementation of asynchronous testing is what inspired the async Jasmine library which we saw in the last module. So, as you can see, mocha's really quite versatile and supports a lot of different styles of testing.

Mocking
Joe Eames: Hello, this is Pluralsight's course on Testing Clientside JavaScript. In this module and in the next two modules we will be discussing Mocking in JavaScript. We'll start in this module with an introduction to mocking in which we'll talk about mocking in general, why we do it, and what the benefits and drawbacks are. We'll discuss the different types of mocks and how mocking is different in JavaScript than a language like java or C-sharp. Then, we'll look at how we might go about writing our own mocking library so that we can understand a little better how JavaScript mocking libraries actually work. And in the following modules we will cover two mocking tools. We'll start with Jasmine and look at Spy's functionality. Then we will move on to Sinon. JS, which is a library solely dedicated to mocking in JavaScript. This is a large library so we will spend quite a bit of time looking at the different ways we can mock using Sinon. And note about vocabulary. I have used the term system under test or SUT in previous modules and I will continue to do so in this module, so whenever you hear the term system under test, I'm referring only to the specific part of an entire system or program which I want to test at that moment. Generally, this corresponds to single class, but that isn't always true.

Jasmine Spies
Joe Eames: Hello. This is Pluralsight's course on testing client-side JavaScript. In this module we will be looking at Jasmine Spies. In the introduction I mentioned two mocking libraries that we will look at, Jasmine Spies and Sinon. JS. We're going to start with Jasmine Spies first since their functionality is a bit simpler than what we will find in Sinon. JS. In fact, you might say that spies in Jasmine are pretty much a subset of the functionality in Sinon. Albeit, they have a nice tight integration with Jasmine so there are built-in matchers for using spies that Sinon doesn't have, but other than that there is little functionality available in Jasmine Spies that isn't available in Sinon. JS. The first thing to note about spies in Jasmine is that with only a single exception which we'll cover in a minute, spies in Jasmine are built around mocking a single function, whether that is a freestanding function or a single method on an object. Because of that, they are great for mocking callbacks and other functions that operate alone, but when you need to mock every function in an object, they can do this, but they are a bit unwieldy. The next thing to take note of in Jasmine Spies is that they support both scenarios we discussed in our manual mocking, namely, replacement mocking, where the spy completely replaces the actual method, and pass-through mocking, where the spy only records the information about the call but still passes the execution off to the real method; and lastly, as I mentioned just a second ago, Jasmine Spies have a set of matchers built into Jasmine for bricking with them. So the integration is very nice, and the code to assert on a spy is very readable. Also, remember you can create your own custom matchers in Jasmine. So if there's any one that you feel is missing, it's easy to create it.

Sinon
Hello. This is Pluralsight's course on Testing Clientside JavaScript. In this module, we will covering SinonJS. Sinon was created in 2010 by Christian Johansen as part of the work he did while writing the book, Test-Driven JavaScript Development. The website for that book is at tddjs. com. Sinon is a complete mocking library for JavaScript. Pretty much everything we saw with Jasmine spies is available with Sinon. In addition to that, Sinon can do quite a bit more. That doesn't mean that Jasmine spies aren't sufficient for your mocking needs while testing. Of course, that really depends on your usage, but again, Sinon is very comprehensive. It has a very popular mocking library. The official URL for SinonJS is here, and it has a link to download the latest version. The documentation on that site is really pretty good, so it's a great place to go for a refresher on how to do something with Sinon.

Testing Utilities
Hello. I'm Joe Eames and this is Pluralsight's course on Testing Clientside JavaScript. In this module we will be coving three utilities for testing clientside JavaScript. Now by no means should you think for even a moment that there's three utilities we cover are the only testing utilities that you may find useful in your JavaScript testing. Like all open source development and especially JavaScript there is a veritable plethora of tools and utilities available that you may find useful when testing clientside JavaScript. The reasons that I chose these three tools to look at out of all the utilities out there is primarily because of my belief that they cover a decent range of options and currently their popularity is growing whereas other utilities may not be gaining as much in popularity or are too new or not widely used enough to be considered mainstream. All these utilities revolve around one common thing, running your tests as you change your code. All of them offer one common piece of functionality. They will watch your files and rerun your tests whenever you change a file be that a spec file or a code file. This ability is really nice when writing code because we will know at the soonest possible moment that you have broken one of your tests and you can react to it immediately. The three utilities we will cover are Live Reload, Testacular and Grunt. Live Reload is a simple way to make a browser reload whenever a file from a specified set of directories changes. Testacular is a testing utility that runs tests in multiple browsers. And Grunt is a build tool which has among many features, the ability to run tests on the command line. So without further ado, let's look at our first tool.