Unit testing is the process of testing the behavior of independent “units” of your code. Your tests check if a “unit” is given a controlled input it returns the expected output. A “unit” is the smallest piece of code in your project that can be tested by itself. Often, this will be a single function, method, or class.

In this example, we are examining a JavaScript variable named multiplyKittens that contains a function. This function takes two parameters, “kittens” (that represents the number of kittens you begin with) and “multiplier” (the value you want to multiply your kittens by). This function will be the “unit” we test our assumptions on.

var multiplyKittens = function(kittens, multiplier) {
var kittenNumber = kittens * multiplier;
return kittenNumber;
}

Our assumption about this unit is that if you supply it with two numbers as parameters you will get back the result of those numbers multiplied together.

In order to test this unit, I write a “suite” of unit tests using a JavaScript framework called Jasmine.js, which makes it easy for me to write suites of tests. A suite is a collection of related unit tests, and they will live in a file (or files) that are separate from the code you are testing. Often developers design theses suites to run automatically before the code is pushed to your web server (and live to the public!).

describe("Kitten Testing Suite", function() {
it("correctly multiplies the number of kittens", function() {
expect(multiplyKittens(5, 10)).toBe(50);
expect(multiplyKittens(7, 7)).toBe(49);
});
});

The “describe” function takes two arguments, the name of the suite (our suite name is “Kitten Testing Suite”) and a function that will include all of our unit tests.

The “it” function is called a spec, it contains the expectations we have for this unit. It takes two arguments, the name of the spec and a function that contains the expectations (sometimes known as “assertions”) we want to run on this unit.

The “expect” functions are our assertions or expectations. This just means we are asserting that if we supply the function multiplyKittens() with 5 and 10 the function should return the number 50. The same goes for 7 and 7, if we supply the multiplyKittens() function with 7 and 7, it should return the number 49.

When we run this suite it will tell us if our assertions passed or failed (and, luckily both of our assumptions passed!).

Why Should I Unit Test?
Unit testing is the best way to ensure that your code is working properly, and more importantly, it’s the best way to ensure that you’re only writing the code you really need for your web application.

Unit testing while you are writing your code allows you to write and test your code incrementally, so you will find bugs sooner and identify unnecessary code as you write it, rather than months down the line when that code snippet is wreaking havoc on other parts of the website.

What Should I Unit Test?
It’s recommended that, at least, you test your public functions, methods and classes (Here, the school of thought is that you assume your private, or internal, methods are working correctly).

Your should test one specific assumption at a time.

Each unit must be independent and not depend on the output of another unit (this means your tests should be able to run in any order).

Some General Thoughts to Unit Tests
The prevailing thought on Unit Testing is, “test behavior, not implementation.” This means you shouldn’t worry about the “implementation details” of each unit, just the end result. In our example an “implementation detail” would be the multiplication operator (the asterisk * symbol). We didn’t test that it worked correctly, just that the final number returned from the function was what we expected.

You generally don’t unit test private methods directly. Many developers consider them to be an implementation detail. However, other developers consider unit tests to be a “code contract” and use them as documentation of all the methods, functions, and classes in a software project. It’s up to you and your team if you wish to test every unit (private or public) as a source of internal documentation, or just test the public API.

One Last Note
Unit tests are not designed to find bugs in your code (I wish it were that easy!). Unit tests only test each piece of functionality separately, and it does not test that the entire system as a whole is working correctly. If you are looking for an automatic way to find bugs in your project Integration testing might be what you are looking for.

This is a very brief outline, and many details were omitted. If you want to learn more, start by reading the Jasmine.js documentation.

And if you’re really ready to level up, go check out Sinon.js.

Martha Gridler is a Software Engineer at Etsy and an alumni of NYC’s Hacker School. Martha is pink and fluffy on the outside, hard and code crunchy on the inside. And sometimes, she speak at conferences about programming. Follow her on Twitter @marthakelly or read more of her writing.