Coming from a PHP background and with PHPUnit testing, I started my journey into writing tests on NodeJs with some expectations. For most, I was disappointed but for some, I was blown away. I guess this is a feeling you have to get used to with JavaScript. PHPUnit Vs Jest PHPUnit provides you with more test functions to work with, has better error tracing, and is easier to debug. However, testing on NodeJs is faster than testing with PHPUnit. Correction: testing on NodeJs is than testing with PHPUnit, because Jest runs your tests in parallel, and in the world of CI/CD, this means something very important. Fast deployment time! 🙌🏽 way faster This is great, however, working with tests that run in parallel comes with its own challenges. Tips for Testing on NodeJs Using Jest Beware of Asynchronous Access to Data Tests running in parallel means that you will have multiple tests making requests to the database at the same time. Expect inconsistency from tests like this. // Get User Test
 test('get user', async () => {
    const response = await request
      .get('/v1/user/1')
      .set('Authorization', `Bearer sample-token`)
      .send();

    expect(response.status).toBe(200);
 });

// Delete User Test
 test('delete user', async () => {
    const response = await request
      .delete('/v1/user/1')
      .set('Authorization', `Bearer sample-token`)
      .send();

    expect(response.status).toBe(200);
 }); The Problem The "Get user" test is going to be inconsistent depending on which of the tests runs first. If the "Delete User" test runs first, the "Get User" test will fail by the time it runs because the user will no longer exist. The Solution Ensure that each test works with its own unique data. // Get User Test
 test('get user', async () => {
    // Create a new user
    const user = User.create({name: "Sample user 1"});
   // Get the user
    const response = await request
      .get(`/v1/user/${user.id}`)
      .set('Authorization', `Bearer sample-token`)
      .send();

    expect(response.status).toBe(200);
 });

// Delete User Test
 test('delete user', async () => {
    // Create a new user
    const user = User.create({name: "Sample user 2"});
    // Delete the user
    const response = await request
      .delete(`/v1/user/${user.id}`)
      .set('Authorization', `Bearer sample-token`)
      .send();

    expect(response.status).toBe(200);
 }); Always Remember Your Promises Always remember to await functions that return a promise. Obvious right? I will bet you still forgot one some minutes ago. On a serious note, these kinds of errors in tests can mess up your week and are difficult to detect. For example: const user = User.findByPk(1); // no await
expect(user).not.toBeNull(); The Problem This will always be true as it will be testing on the returned object which will not be null. Promise The Solution Await const user = await User.findByPk(1); // await 
expect(user).not.toBeNull(); Prefer Debugger to console.log Debugger adds more flare to error tracing, get used to it. Debuggers allow you to literally go into the function and see what happens step by step and view the real content of each variable at any point, while only shows you the string representation of the variable you log which could be hiding that extra piece of information you need to figure the bug out. console.log Additionally, codes can easily find their way to production and you find yourself unknowingly logging sensitive information which could be dangerous. console.log Mock Calls to External APIs or Resources This is more of a general tip when testing with any framework. For most, your test should focus on testing the functions and features of your app, not the functionality or output of an external application. Avoid consuming external resources during tests as this could introduce inconsistencies to your code when those requests fail and also increase the time your tests take to run. It's best practice to mock these resources or API responses instead. Example: const getSignedUrl = (key, bucket = null) => {
  if (process.env.NODE_ENV === 'test') {
    return `https://s3.eu-west-2.amazonaws.com/sample/${key}`;
  }

  return s3.getSignedUrl('getObject', {
    Bucket: bucket,
    Key: key,
    Expires: 60,
  });
}; Also published on . https://log.victoranuebunwa.com/how-i-survive-testing-on-nodejs-and-jest

Using AWS Lambda to Reduce NodeJS App Size

Portfolio

2021 - HackerNoon Contributor of the Year - NODEJS

2021 - HackerNoon Contributor of the Year - TESTING

2021 - HackerNoon Contributor of the Year - CODING

Nominated for 2022 - HackerNoon Contributor of the Year - Coding Skills

Nominated for 2022 - HackerNoon Contributor of the Year - Aws

Nominated for 2022 - HackerNoon Contributor of the Year - Amazon

Nominated for 2022 - No No No Nodejs

Too Long; Didn't Read

How to Survive Testing on NodeJs and Jest 🤒

How to Survive Testing on NodeJs and Jest 🤒

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Avoiding ‘Too Many Connections’ in Lambda + RDS Workflows

Testing with Jest: An Introduction

25 Stories To Learn About Jest

A Beginners Guide to Learn Mock Fetching in jest

A Beginner's Guide to Unit Testing In JavaScript

A guide to TDD a React/Redux TodoList App — Part 1

Avoiding ‘Too Many Connections’ in Lambda + RDS Workflows

Testing with Jest: An Introduction

25 Stories To Learn About Jest

A Beginners Guide to Learn Mock Fetching in jest

A Beginner's Guide to Unit Testing In JavaScript

A guide to TDD a React/Redux TodoList App — Part 1

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps