3

In my code that needs testing I use

import dayjs from 'dayjs';
import utc from 'dayjs/plugin/utc';
dayjs.extend(utc);

dayjs().add(15, 'minute')

In my test I need to mock dayjs in order to always have the same date when comparing snapshots in jest so I did

jest.mock('dayjs', () =>
  jest.fn((...args) =>
    jest.requireActual('dayjs')(
      args.filter((arg) => arg).length > 0 ? args : '2020-08-12'
    )
  )
);

It fails with

TypeError: _dayjs.default.extend is not a function

Unfortunately similar questions on here didn't help me. How could I mock both default dayjs but also extend?

jonrsharpe
  • 115,751
  • 26
  • 228
  • 437
ver.i
  • 526
  • 1
  • 5
  • 13
  • Try not to mock dayjs, you don't own that interface. Treat time as a dependency, so you can mock out your own module that returns a Date - then use `dayjs(yourFunction())`. – jonrsharpe Dec 03 '20 at 17:11

3 Answers3

4

You could write a more thorough manual mock for dayjs, one that has the extend method, but then you're coupling your tests to a 3rd party interface. "Don't mock what you don't own" - you'll end up having to recreate more and more of the dayjs interface in your mock, and then if that interface changes your tests will continue to pass but your code will be broken. Or if you decide to swap to a different time library, you have to rewrite all of your tests to manually mock the new interface.

Instead, treat time as a dependency. Have your own function, in your own module, that simply provides the current time as a Date object:

export const howSoonIsNow = () => new Date();

Then, when you need to create a dayjs object, do so from that (dayjs() is equivalent to dayjs(new Date()) per the docs):

import dayjs from 'dayjs';
import utc from 'dayjs/plugin/utc';

import { howSoonIsNow } from './path/to/noTimeLikeThePresent';

dayjs.extend(utc);

dayjs(howSoonIsNow()).add(15, 'minute');

Now in your test you can swap out something you actually own, and not have to interfere with dayjs at all:

import { howSoonIsNow } from './path/to/noTimeLikeThePresent';

jest.mock('./path/to/noTimeLikeThePresent');

howSoonIsNow.mockReturnValue(new Date(2020, 8, 12));

Now if a new version of dayjs changes in a way that breaks your use of it, your tests will fail and tell you as much. Or if you swap to a different time library (here's an example using Moment) you don't have to rewrite all of your tests, so you can be confident you've swapped over correctly.

Also FWIW I don't rate snapshot testing in general - it just becomes change detection, failing for irrelevant changes and encouraging people to ignore the test results and blindly recreate the snapshots if anything fails. Test based on the behaviour you want to see from your components.

jonrsharpe
  • 115,751
  • 26
  • 228
  • 437
  • Totally agree on the last comment, snapshot testing tends to do more harm to be honest. – Crysfel Aug 05 '21 at 19:34
  • What if you want to unit test your `howSoonIsNow` function. You would still need to mock dayjs – Nikhil Nanjappa Jun 27 '22 at 11:45
  • @NikhilNanjappa `howSoonIsNow` doesn't depend on `dayjs` at all. It's also trivial enough that you could reasonably decide it doesn't need testing at the unit level at all. The point is to invert the dependency on _time_, to make the code around it more testable. – jonrsharpe Jun 27 '22 at 11:49
0

You can try this:

jest.mock('dayjs/plugin/utc', () => ({
  default: jest.requireActual('dayjs/plugin/utc'),
}));

It works for me.

Anros Nguyen
  • 31
  • 3
-1

Mock dayjs like you wish and don't forget to set the static function as follows:

import dayjs from "dayjs";

jest.mock('dayjs', () =>
  jest.fn((...args) =>
    jest.requireActual('dayjs')(
      args.filter((arg) => arg).length > 0 ? args : '2020-08-12'
    )
  )
);

dayjs.extend = jest.fn();
castor
  • 11
  • 3