Register to get access to 15+ free programming courses with interactive exercises

Unit Tests JS: Automated testing

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

Аватары экспертов Хекслета

Are there any more questions? Ask them in the Discussion section.

The Hexlet support team or other students will answer you.

For full access to the course you need a professional subscription.

A professional subscription will give you full access to all Hexlet courses, projects and lifetime access to the theory of lessons learned. You can cancel your subscription at any time.

Get access
130
courses
1000
exercises
2000+
hours of theory
3200
tests

Sign up

Programming courses for beginners and experienced developers. Start training for free

  • 130 courses, 2000+ hours of theory
  • 1000 practical tasks in a browser
  • 360 000 students
By sending this form, you agree to our Personal Policy and Service Conditions

Our graduates work in companies:

<span class="translation_missing" title="translation missing: en.web.courses.lessons.registration.bookmate">Bookmate</span>
<span class="translation_missing" title="translation missing: en.web.courses.lessons.registration.healthsamurai">Healthsamurai</span>
<span class="translation_missing" title="translation missing: en.web.courses.lessons.registration.dualboot">Dualboot</span>
<span class="translation_missing" title="translation missing: en.web.courses.lessons.registration.abbyy">Abbyy</span>
Suggested learning programs

From zero to a developer. Refunds in case you won't get a job

Frontend Developer icon
Profession
New
Development of front-end components for web applications
start anytime 10 months

Use Hexlet to the fullest extent!

  • Ask questions about the lesson
  • Test your knowledge in quizzes
  • Practice in your browser
  • Track your progress

Sign up or sign in

By sending this form, you agree to our Personal Policy and Service Conditions

Toto Image

Ask questions if you want to discuss a theory or an exercise. Hexlet Support Team and experienced community members can help find answers and solve a problem.