Victor Queiroz

Jasmine: First Contact with Unit Testing

Gone are the days when we developers tested our applications by hand — going to a browser, opening page by page, and sprinkling console.log everywhere to check if things were returning what we expected. For those who don’t know it yet, let me introduce an excellent unit testing framework that will change the way you develop your applications. Hahaha! Let’s go! :D

Introduction

What is Jasmine?

Jasmine is a behavior-driven development framework for testing JavaScript code. It doesn’t depend on any other JavaScript framework. And the best part is that it has a clean and obvious syntax, so you can write tests that are clean and easy for any developer to understand.

Let’s type some code

What is a test suite?

A test suite is nothing more than a suite where you place all the tests belonging to it. It’s more aesthetic than functional, so to speak. Example: I have a test suite called “application module,” and inside it I have several tests that will test my controllers and other features of the application module.

Some of the functions Jasmine provides

describe (describeName, function)

Creates a new test suite.

it (testDescription, function)

Creates a new test. It’s inside the it’s where the tests actually happen.

Conventions

It’s important that you maintain a convention when defining the testDescription. For this, you’ll need a basic understanding of English.

The it function is named that way for a very simple reason — it allows you to define a test in a clean, natural-language way, so that anyone who reads it can easily understand what you wrote. When defining a new test, I won’t write it like it('application module: version test', fn). Instead, I’ll write the testDescription as: it('should have a version', fn) — meaning I literally completed what the function “started saying”: “it should have a version.” Makes sense?

Notes

An it cannot be called outside of a test suite. Example:

describe('application module', function () {
  it('should have a version', function () {
    // tests should happen here
  });
});

WRONG:

describe('application module', function () {
  // ???
});

it('should have a version', function () {
  // tests should happen here
});

beforeEach (function)

This function will be resolved before each test within a suite starts executing.

afterEach (function)

This function will be resolved after each test within a suite finishes executing.

expect (value)

Must always be inside a test. It’s the final part of a test — this function lets you verify if value equals the expected value. It’s essentially what we call a test. In value, as the parameter name suggests, you pass any value. This function returns another function, and you can use it in several ways to finalize the test:

  • toBe(value) — Checks if value (from expect) is identical to value (from toBe)
  • toEqual(value) — Checks if value (from expect) equals value (from toEqual)
  • toBeDefined() — Checks if value has been defined
  • toMatch(match) — Runs a regular expression on value and returns true if it finds a match
  • toBeUndefined() — Checks if value is undefined

All of the functions above can be used after a .not, which will make them operate in the opposite way. Example:

describe('application module', function () {
  it('should do something', function () {
    expect(true).not.toBe(false);
    expect(true).toBe(true);
    expect(true).not.toBeUndefined();
  });
});

Well, I hope you enjoyed it. Until next time, and remember — FOLLOW THE CONVENTIONS! Leave your questions below, and I’ll do my best to help everyone. Cheers! :)

Comments