DEV Community: Edwin Wong

jest.clearAllMocks vs jest.resetAllMocks vs jest.restoreAllMocks explained

Edwin Wong — Wed, 31 Aug 2022 16:08:57 +0000

I know is been hard to remember and confuse about what these clearAllMocks, resetAllMocks and restoreAllMocks actually does and why we need that?

Allow me to clear your mind!

jest.clearAllMocks

Clear all mock usage data such as mock.calls, mock.instances, mock.contexts and mock.results but not their implementation.

Every time the mock function get called it will keep those usage contexts into the mock function object itself.

Let's take a following example. We going to test the getRandomNumber that actually calling randomNumberGenerator() to get the random number. So, In this case we will mock the random.service module.

// main.test.js
jest.mock('random.service')

const { randomNumberGenerator } = require('random.service')

const getRandomNumber => randomNumberGenerator()

it('should return a number', () => {
  randomNumberGenerator.mockReturnValue(7)
  const num = getRandomNumber()

  console.log(randomNumberGenerator.mock) // 👈 check this out!

  expect(num).toBe(7)
})

Once you call getRandomNumber function, the mock randomNumberGenerator will also get called accordingly. After this, you can console.log(randomNumberGenerator.mock) and you will see something like this.

{
  calls: [ [] ],
  contexts: [
    <ref *1> {...}
  ],
  instances: [
    <ref *1> {...}
  ],
  invocationCallOrder: [ 1 ],
  results: [ { type: 'return', value: 2 } ],
  lastCall: []
}

The contexts will be useful for some assertions purpose like to expect number of calls, do function have return and more. This also could be useful for certain use case that may need these context for cross test case assertions.

However, this also could lead to some problem if you don't clear it. Example below

it('example 1', () => {
  randomNumberGenerator.mockReturnValue(7)
  const num = getRandomNumber()
  expect(randomNumberGenerator).toBeCalledTimes(1)
})

it('example 2', () => {
  randomNumberGenerator.mockReturnValue(8)
  const num = getRandomNumber()
  expect(randomNumberGenerator).toBeCalledTimes(1) // This will failed!! because it expect 2 times.
})

The second example will failed and this is because the mock.calls has 2 counts. To fix it, you need to use jest.clearAllMocks in jest global like afterEach or beforeEach

beforeEach(() => {
  jest.clearAllMocks()
})

This tell jest to clear all the mock usage data before the next test case start.

jest.resetAllMocks

A superset of clearAllMocks() and it also reset the mock function implementations with brand new jest.fn().

By default, all mock function without implementation it will always return undefined. And once added implementation it will keep the implementation in the mock function object.

Following code will explain everything.

it('example 1', () => {
  randomNumberGenerator.mockReturnValue(7)
  const num = getRandomNumber()
  expect(num).toBe(7)
})

it('example 2', () => {

  // we didn't mock `randomNumberGenerator` in this test but this will return 7 because the last test case is added implementation.
  console.log(randomNumberGenerator())

  const num = getRandomNumber()
  expect(num).toBe(7)
})

This is useful when you need re-usable the mock function. So you don't have to write again in every test case.

If you want every test case is fresh, new and standalone. You should use it before each test case start. It can ensure side effect free for each test case and worry less.

jest.restoreAllMocks

Restore all mock back to their original implementation and it only works for mock was created with jest.spyOn.

For some reason, you need to mock the module partially with certain function. A classic example will be testing the date time related as following example.

it('should be my birthday', () => {
  jest.spyOn(Date, 'now').mockReturnValue('2022-08-31T15:23:19.576Z')
  const result = isTodayMyBirthday()
  expect(result).toBe(true)
})

This works well but it is dangerous because spyOn is kind of like mutate the module object and if you forgot to restore all mocks, the subsequent test is using the mock version of Date.now() and this is not really obvious and hard to debug.

Like previous solution did, just clear it before every next test case.

beforeEach(() => {
  jest.restoreAllMocks()
})

Be cautions when you see spyOn in your test case it could be the reason to make your test failed.

Conclusion

As you can see, the mock API behavior is always keep the state and you have to clear/reset/restore it explicitly. There is a better to do this if you want your test case always start with a new fresh and side effect free. You can do it in jest config.

// jest.config.js

const config = {
  clearMocks: true,
  resetMocks: true,
  restoreMocks: true
}

I hope this will help you have better understanding. Like or Unicorn or Save if it does help! Thank you.

Array print()

Edwin Wong — Sat, 06 Aug 2022 16:03:00 +0000

How troublesome every time console.log to each array chain method result for debugging?

Let's see following code

const fruits = [🍌, 🍎, 🍎, 🍍, 🍌, 🥝, 🥝, 🥝]
const result = fruits
                     .filter(emoji => [🥝, 🍌].includes(emoji))
                     .map(emoji => emoji === 🍌 ? 🍋 : emoji)

console.log(result) // [🍋, 🍋, 🥝, 🥝, 🥝]

Nothing wrong with the code, just when the result is not what you expect, often you will need to trace back and print out each chain method result to find out which part doing wrong.

You probably do this during debug

const fruits = [🍌, 🍎, 🍎, 🍍, 🍌, 🥝, 🥝, 🥝]
const getKiwiNBanana = fruits.filter(emoji => [🥝, 🍌].includes(emoji))                    
console.log(getKiwiNBanana) // [🍌, 🍌, 🥝, 🥝, 🥝]
const result = getKiwiNBanana.map(emoji => emoji === 🍌 ? 🍋 : emoji)
console.log(result) // [🍋, 🍋, 🥝, 🥝, 🥝]

Ok~ you did but you write more code and it is not that elegant.

Array.print()

Add this code in your app root and global level. With this minor extend functionality of Array that allow you to print the result effortless and elegant. You might cautious about eslint error no-extend-native, but don't be so worry if you are not extend existing built-in method and you shouldn't do it!

Typescript

To support Typescript, add this following code in your root level.

declare global {
  interface Array<T> {
    print(): T[]
  }
}

Now you can easily print each chain method result.

const fruits = [🍌, 🍎, 🍎, 🍍, 🍌, 🥝, 🥝, 🥝]
const result = fruits
                     .filter(emoji => [🥝, 🍌].includes(emoji))
                     .print() // [🍌, 🍌, 🥝, 🥝, 🥝]
                     .map(emoji => emoji === 🍌 ? 🍋 : emoji)
                     .print() // [🍋, 🍋, 🥝, 🥝, 🥝]

Looks clean and neat!

There are many thing you can do in the print function like prefix string so that easy for you to search and debug. Or maybe you want disable print in production mode. I will leave it to you to handle this.

Do ❤️ it if it's help! Hope your enjoy.

How to mock function that called inside module

Edwin Wong — Fri, 10 Jun 2022 07:58:22 +0000

Problem

Iets say you have the file

// file.js

export function b() {
    return 'B'
}

export function a() {
    return b()
}

module.exports = {
    a,
    b,
}

function a is calling function b internally. To mock the function b can be very difficult.

You will probably do something like this in your test

Using jest.mock method

jest.mock('./file', () => {
    const original = jest.requireActual('./file')
    return {
        ...orignial,
        b: jest.fn()
    }
})

const f = require('./file')

test('a', () => {
    f.b.mockReturnValue('C')

    expect(f.a()).toBe('C')
    // this will failed, it got 'B'
})

Using jest.spyOn method

const f = require('./file')

test('a', () => {
    jest.spyOn(f, 'b').mockReturnValue('C')

    expect(f.a()).toBe('C')
    // it sill failed!, it got 'B'
})

This is not a bug, above 2 methods are working fine. The main reason is because the reference point. Once the function is mocked and print it out you will see something like this.

[Function: b] {
    _isMockFunction: true,
    getMockImplementation: [Function (anonymous)],
    mock: [Getter/Setter],
    mockClear: [Function (anonymous)],
    mockReset: [Function (anonymous)],
    mockRestore: [Function (anonymous)],    
    ...
    ...
}

Now you try print out the function b that called in function a. And, run the test again.

export function a() {
    console.log(b) // it will print [Function: b] (without the mock property)
    return b()
}

Solution 1

Move function b to another file.

// b.js
export function b() {
    return 'B'
}

// file.js
import {b} from "./b"

export function a() {
    return b()
}

In this case, just mock b will do. I believe you know better than me.

Solution 2

Using the same reference point. This could be abit ugly to you codebase. I think is fine for me.

// file.js

export function b() {
    return 'B'
}

export function a() {
    return module.exports.b() // magic here
}

module.exports = {
    a,
    b,
}

Or you can do something like, if this is the way you define your module.

// file.js

module.exports = {
    b: () => {
        return 'B'
    },
    a: () => {
        return this.b() // this magic
    }
}

Both are achive the same result and same principle.

How test script help you write a safety code?

Edwin Wong — Wed, 29 Jul 2020 17:33:40 +0000

Code without test script is like writing an essay without proofreading. End up, full of grammar mistake and typo and is kinda bad for reader. Same goes to code will become buggy and not reliable.

Write a test script may not completely away from bug but it also depends on how comprehensive test you write, the more comprehensive test the more code confident you have.

Let's look at this example...

function multiply(num1, num2) {
  return num1 * num2
}

multiply(1, 2) // 2

It is a simple multiply function, now let's write test for this function.

test('with 1 * 2', () => {
  expect(multiply(1, 2)).toBe(2)
})

test('with times zero', () => {
  expect(multiply(1, 0)).toBe(0)
})

Now, your code is tested but not completely. Let's see...

multiply(2) // NaN
multiply('o', 1) // NaN
multiply() // NaN

See~ We often write the test script in our expected way. This will only ensure the result is expected provided with valid input. What about invalid input? To write a better test script you have to think in negative or unexpected way.

So, we need to improve our function handling.

function multiply(num1, num2) {
  if (!num1 || !num2) throw 'Invalid or missing params'
  return num1 * num2
}

and update our test script also.

test('without input', () => {
  expect(multiply()).toBeThrow()
})

test('with invalid input', () => {
  expect(multiply(null, 2)).toBeThrow()
  expect(multiply(null, undefined)).toBeThrow()
})

You think now is safe, but not yet! let's see this...

multiply('a', 'b') // NaN

Gotcha! the way we check is only for parameter undefined or empty. By passing in 2 params with different type it still can pass our test. Let's improve again.

function multiply(num1, num2) {
  if (!num1 || !num2) throw 'Invalid or missing params'
  if (!/^[0-9]+/.test(num1) || !/^[0-9]+/.test(num2)) throw 'Invalid params'
  return num1 * num2
}

// test script
test('with invalid input', () => {
  expect(multiply(null, 2)).toBeThrow()
  expect(multiply(null, undefined)).toBeThrow()
  expect(multiply('a','b')).toBeThrow()
})

Now, our test is comprehensive and bug free. During development, you may not cover all the use case to test and it is also impossible to know all the use case. That's fine, just fix it while you face it.

The more use case are cover the less bug that we can ensure.

Thank you for Reading!

feel free to comment is there a better way!

Tips to create a constants file in Javascript

Edwin Wong — Sat, 07 Mar 2020 16:06:53 +0000

It shouldn't be difficult to just create a constants file and keep all your value in one place, so the tips how to define the const value is something I want to share about.

Let's see the example

// constants.js

const paymentMethods = [
  {
    key: 'STRIPE',
    value: 1,
    title: 'Stripe Payment', 
  },
  {
    key: 'PAYPAL',
    value: 2,
    title: 'Paypal Payment',    
  },
  {
    key: 'AMAZON_PAYMENT',
    value: 3,
    title: 'Amazon Payment',    
  }
]

const shippingMethods = [
  'SKYNET',
  'GDEX',
  'DHL',
  'UPS',
]

Nothing is wrong with the example approach. It works fine and most of the developer will do the same like this. However, it can be a little bit hard to access particular value you want e.g access the amazon payment method object.

I believe you probably will do something like this.

paymentMethods.find(method => method.key === 'AMAZON_PAYMENT')

Actually, there is a another way...

Store in key value object instead of array

// constants.js

const paymentMethods = {
  STRIPE: {
    key: 'STRIPE',
    value: 1,
    title: 'Stripe Payment', 
  },
  PAYPAL: {
    key: 'PAYPAL',
    value: 2,
    title: 'Paypal Payment',    
  },
  AMAZON_PAYMENT: {
    key: 'AMAZON_PAYMENT',
    value: 3,
    title: 'Amazon Payment',    
  }
}

const shippingMethods = {
  SKYNET: 'SKYNET',
  GDEX: 'GDEX',
  DHL: 'DHL',
  UPS: 'UPS',
}

Store it as object is good for direct access particular value you need. Sometimes you just need list few options rather than all.

paymentMethods.AMAZON_PAYMENT

// {
//    key: 'AMAZON_PAYMENT',
//    value: 3,
//    title: 'Amazon Payment',    
// }

For loop through the object

Object.keys(paymentMethods).map(key => {
  console.log(paymentMethods[key])
})

That's it! Feel free to comment if there is better way~