Unit Tests — JS: Automated testing

• Testing basic features
• Testing additional features
  • Borderline cases

The information we've learned is good enough for testing in everyday development. Before we dive into the more complex topics and features of Jest, let's go through the entire library testing process and talk about the test structure and good and bad practices. This will help to form the right attitude towards testing in general.

In this lesson, we'll cover the basics of unit testing. This type of testing is aimed at checking program modules individually. These tests usually test basic language constructs, such as functions, modules, and classes. They don't give any guarantees about the performance of the whole application, but they're of great help when a module in a program is particularly complex

Let's try to test a code that implements a stack. Remember that a stack is a list of elements organized according to the LIFO principle. The last piece of data put into the stack is the first one to come out. Stacks themselves serve to implement algorithms. They're often used in low-level code, for example, within programming languages or operating systems.

import makeStack from '../src/stack.js';

const stack = makeStack();
stack.isEmpty(); // true
stack.push(1); // (1)
stack.push(2); // (1, 2)
stack.push(3); // (1, 2, 3)
stack.isEmpty(); // false
stack.pop(); // 3. In the stack (1, 2)
stack.pop(); // 2. In the stack (1)
stack.pop(); // 1. The stack is empty
stack.isEmpty(); // true

First, let's solve the organizational issues. Assuming the stack is implemented in src/stack.js, we put its test in __tests__/stack.test.js.

Testing basic features

Let's write our first test. The first test should always test a positive scenario, and it should involve the main feature of the component being tested:

import makeStack from '../src/stack.js';

test("stack's main flow", () => {
  const stack = makeStack();
  // add two elements to the stack and then retrieve them
  stack.push('one');
  stack.push('two');
  expect(stack.pop()).toEqual('two');
  expect(stack.pop()).toEqual('one');
});

This test verifies that the two main methods work correctly without considering borderline cases. To do this, two matchers are executed inside the test, and they take turns checking the values to be extracted from the stack.

You can find people all over the internet saying that putting several checks in one test is wrong. And the tests need to be as detailed as possible, and that you need to create a new test for each check.

test("stack's main flow", () => {
  const stack = makeStack();
  stack.push('one');
  stack.push('two');
  expect(stack.pop()).toEqual('two');
});

test("stack's main flow", () => {
  const stack = makeStack();
  stack.push('one');
  stack.push('two');
  stack.pop();
  expect(stack.pop()).toEqual('one');
});

This approach often leads to serious code bloat and many duplications, yet there's no explicit benefit to this, however. The only time we need a separate test is when there's a different script that needs another data and performs a different sequence of actions.

Testing additional features

The next test will focus on additional stack features. This includes the isEmpty() function that checks if the stack is empty:

test('isEmpty', () => {
  const stack = makeStack();
  expect(stack.isEmpty()).toBe(true);
  stack.push('two');
  expect(stack.isEmpty()).toBe(false);
  stack.pop();
  expect(stack.isEmpty()).toBe(true);
});

This test tests three situations at once:

• initial stack state
• the state of the stack after adding elements
• the state of the stack after extracting all the elements

In principle, this should be enough. However, it is theoretically possible for isEmpty() to break anyway. Do we need to try and go down all the possible paths? Not really. Tests aren't exactly a dime a dozen, every line of code written may need to be changed in the future to fix errors. If there are doubts about whether you should write a test or not, it's better not to. This is how you can work out the minimum number of tests you should write, after that, they become less effective. Rare situations require test coverage only when they are critical to performance.

Borderline cases

The last thing you can test is the behavior of the pop() function when there are no elements in the stack. By design, stacks throw an exception if an attempt is made to take an item from it when it's empty. In other words, this is considered a situation that should not happen, developers should always make sure that the stack is not empty.

test('pop in empty stack', () => {
  const stack = makeStack();
  // The pop method call is wrapped in a function
  // otherwise the matcher won't be able to catch the exception
  expect(() => stack.pop()).toThrow();
});

But borderline cases aren't always so easy to see. It's unlikely that any programmer could write all the required tests in one go. If there's a bug in the code not yet covered by tests, you should first write a test that reproduces the bug and then fix it. This is the only way to maintain a sufficient level of reliability without turning development into a continuous bug-fix session.

Recommended materials

1. Checklist of Good Software Engineering Practices in Companies