How to use getCoverageOptions method in Jest

Introduction

Unit tests are automated tests written and run by software developers to ensure that a section of an application meets its design and behaves as intended. As if we are talking about object-oriented programming, a unit is often an entire interface, such as a class, but could be an individual method.

The goal of unit testing is to isolate each part of the program and show that the individual parts are correct. So if we consider your ApiService.makeApiCall function:

  static makeApiCall(
    url: string,
    normalizeCallback: (d: ResponseData) => ResponseData | null,
    callback: (d: any) => any
  ) {
    return ApiClient.get(url)
      .then((res: any) => {
        callback(normalizeCallback(res.data));
      })
      .catch(error => {
        console.error(error);
      });
  }

we can see that it has one external resource calling ApiClient.get which should be mocked. It's not entirely correct to mock the HTTP requests in this case because ApiService doesn't utilize them directly and in this case your unit becomes a bit more broad than it expected to be.

Mocking

Jest framework provides great mechanism of mocking and example of Omair Nabiel is correct. However, I prefer to not only stub a function with a predefined data but additionally to check that stubbed function was called an expected number of times (so use a real nature of mocks). So the full mock example would look as follows:

/**
* Importing `ApiClient` directly in order to reference it later
*/
import ApiClient from './apiClient'; 

/**
* Mocking `ApiClient` with some fake data provider
*/
const mockData = {};

jest.mock('./apiClient', function () {

  return {
    get: jest.fn((url: string) => {
      return Promise.resolve({data: mockData});
    })
  }
});

This allows to add additional assertions to your test example:

it('should call api client method', () => {
  ApiService.makeApiCall('test url', (data) => data, (res) => res);
  /**
  * Checking `ApiClient.get` to be called desired number of times 
  * with correct arguments
  */
  expect(ApiClient.get).toBeCalledTimes(1);
  expect(ApiClient.get).toBeCalledWith('test url');  
});

Positive testing

So, as long as we figured out what and how to mock data let's find out what we should test. Good tests should cover two situations: Positive Testing - testing the system by giving the valid data and Negative Testing - testing the system by giving the Invalid data. In my humble opinion the third branch should be added - Boundary Testing - Test which focus on the boundary or limit conditions of the software being tested. Please, refer to this Glossary if you are interested in other types of tests.

The positive test flow flow for makeApiCall method should call normalizeCallback and callback methods consequently and we can write this test as follows (however, there is more than one way to skin a cat):

  it('should call callbacks consequently', (done) => {
    const firstCallback = jest.fn((data: any) => {
      return data;
    });
    const secondCallback = jest.fn((data: any) => {
      return data;
    });
    ApiService.makeApiCall('test url', firstCallback, secondCallback)
      .then(() => {
        expect(firstCallback).toBeCalledTimes(1);
        expect(firstCallback).toBeCalledWith(mockData);

        expect(secondCallback).toBeCalledTimes(1);
        expect(secondCallback).toBeCalledWith(firstCallback(mockData));
        done();
      });
  });

Please, pay attention to several things in this test: - I'm using done callback to let jest know the test was finished because of asynchronous nature of this test - I'm using mockData variable which the data that ApiClient.get is mocked this so I check that callback got correct value - mockData and similar variables should start from mock. Otherwise Jest will not allow to out it out of mock scope

Negative testing

The negative way for test looks pretty similar. ApiClient.get method should throw and error and ApiService should handle it and put into a console. Additionaly I'm checking that none of callbacks was called.

import ApiService from './api.service';

const mockError = {message: 'Smth Bad Happened'};

jest.mock('./apiClient', function () {

  return {
    get: jest.fn().mockImplementation((url: string) => {
      console.log('error result');
      return Promise.reject(mockError);
    })
  }
});

describe( 't1', () => {
  it('should handle error', (done) => {
    console.error = jest.fn();

    const firstCallback = jest.fn((data: any) => {
      return data;
    });
    const secondCallback = jest.fn((data: any) => {
      return data;
    });
    ApiService.makeApiCall('test url', firstCallback, secondCallback)
      .then(() => {
        expect(firstCallback).toBeCalledTimes(0);
        expect(secondCallback).toBeCalledTimes(0);
        expect(console.error).toBeCalledTimes(1);
        expect(console.error).toBeCalledWith(mockError);
        done();
      });
  });
});

Boundary testing

Boundary testing could be arguing in your case but as long as (according to your types definition normalizeCallback: (d: ResponseData) => ResponseData | null) first callback can return null it could be a good practice to check if is the successfully transferred to a second callback without any errors or exceptions. We can just rewrite our second test a bit:

it('should call callbacks consequently', (done) => {
    const firstCallback = jest.fn((data: any) => {
      return null;
    });
    const secondCallback = jest.fn((data: any) => {
      return data;
    });
    ApiService.makeApiCall('test url', firstCallback, secondCallback)
      .then(() => {
        expect(firstCallback).toBeCalledTimes(1);
        expect(firstCallback).toBeCalledWith(mockData);
        expect(secondCallback).toBeCalledTimes(1);
        done();
      });
  });

Testing asynchronous code

Regarding testing asynchronous code you can read a comprehensive documentation here. The main idea is when you have code that runs asynchronously, Jest needs to know when the code it is testing has completed, before it can move on to another test. Jest provides three ways how you can do this:

1. By means of a callback

   it('the data is peanut butter', done => {
     function callback(data) {
       expect(data).toBe('peanut butter');
       done();
     }
   
     fetchData(callback);
   });
   

   Jest will wait until the done callback is called before finishing the test. If done() is never called, the test will fail, which is what you want to happen.

2. By means of promises

   If your code uses promises, there is a simpler way to handle asynchronous tests. Just return a promise from your test, and Jest will wait for that promise to resolve. If the promise is rejected, the test will automatically fail.

3. async/await syntax

   You can use async and await in your tests. To write an async test, just use the async keyword in front of the function passed to test.

   it('the data is peanut butter', async () => {
   const data = await fetchData();
   expect(data).toBe('peanut butter');
   });
   

Example

Here you can find a ready to use example of your code https://github.com/SergeyMell/jest-experiments Please, let me know if something left unclear for you.

UPDATE (29.08.2019)

Regarding your question

Hi, what can I do to mock ./apiClient for success and error in the same file?

According to the documentation Jest will automatically hoist jest.mock calls to the top of the module (before any imports). It seems that you can do setMock or doMock instead, however, there are issues with mocking this way that developers face from time to time. They can be overridden by using require instead of import and other hacks (see this article) however I don't like this way.

The correct way for me in this case is do split mock defining and implementation, so you state that this module will be mocked like this

jest.mock('./apiClient', function () {
  return {
    get: jest.fn()
  }
});

But the implementation of the mocking function differs depending on scope of tests:

describe('api service success flow', () => {

  beforeAll(() => {
    //@ts-ignore
    ApiClient.get.mockImplementation((url: string) => {
      return Promise.resolve({data: mockData});
    })
  });

  ...
});

describe('api service error flow', () => {

  beforeAll(() => {
    //@ts-ignore
    ApiClient.get.mockImplementation((url: string) => {
      console.log('error result');
      return Promise.reject(mockError);
    })
  });

  ...
});

This will allow you to store all the api service related flows in a single file which is what you expected as far as I understand. I've updated my github example with api.spec.ts which implements all mentioned above. Please, take a look.

Short answer

Use require to grab a fresh module in every test function after setting up mocks.

it("should print breakfast (mocked)", () => {
    jest.doMock(...);
    const getMeal = require("../src/meal").default;

    ...
});

or

Turn Food into a function and put a call to jest.mock into module scope.

import getMeal from "../src/meal";
import food from "../src/food";

jest.mock("../src/food");
food.mockReturnValue({ ... });

...

Long answer

There is a snippet in Jest manual that reads:

Note: In order to mock properly, Jest needs jest.mock('moduleName') to be in the same scope as the require/import statement.

The same manual also states:

If you're using ES module imports then you'll normally be inclined to put your import statements at the top of the test file. But often you need to instruct Jest to use a mock before modules use it. For this reason, Jest will automatically hoist jest.mock calls to the top of the module (before any imports).

ES6 imports are resolved in the module scope before any of the test functions execute. Thus for mocks to be applied, they need to be declared outside of test functions and before any modules are imported. Jest's Babel plugin will "hoist" jest.mock statements to the beginning of the file so they are executed before any imports take place. Note that jest.doMock is deliberately not hoisted.

One can study the generated code by taking a peek into Jest's cache directory (run jest --showConfig to learn the location).

The food module in the example is difficult to mock because it is an object literal and not a function. The easiest way is to force a reload of the module every time the value needs to be changed.

Option 1a: Do not use ES6 modules from tests

ES6 import statements must be module scoped, however the "good old" require has no such limitation and can be called from the scope of a test method.

describe("meal tests", () => {
  beforeEach(() => {
    jest.resetModules();
  });

  it("should print dinner", () => {
    const getMeal = require("../src/meal").default;

    expect(getMeal()).toBe(
      "Good evening. Dinner is green beans and rice. Yum!"
    );
  });

  it("should print breakfast (mocked)", () => {
    jest.doMock("../src/food", () => ({
      type: "breakfast",
      veg: "avocado",
      carbs: "toast"
    }));

    const getMeal = require("../src/meal").default;

    // ...this works now
    expect(getMeal()).toBe("Good morning. Breakfast is avocado and toast. Yum!");
  });
});

Option 1b: Reload module on every invocation

One can also wrap the function under test.

Instead of

import getMeal from "../src/meal";

use

const getMeal = () => require("../src/meal").default();

Option 2: Register the mock and call through to real functions by default

If the food module exposed a function and not a literal, it could be mocked. The mock instance is mutable and can be changed from test to test.

src/food.js

const Food = {
  carbs: "rice",
  veg: "green beans",
  type: "dinner"
};

export default function() { return Food; }

src/meal.js

import getFood from "./food";

function formatMeal() {
  const { carbs, veg, type } = getFood();

  if (type === "dinner") {
    return `Good evening. Dinner is ${veg} and ${carbs}. Yum!`;
  } else if (type === "breakfast") {
    return `Good morning. Breakfast is ${veg} and ${carbs}. Yum!`;
  } else {
    return "No soup for you!";
  }
}

export default function getMeal() {
  const meal = formatMeal();

  return meal;
}

__tests__/meal_test.js

import getMeal from "../src/meal";
import food from "../src/food";

jest.mock("../src/food");

const realFood = jest.requireActual("../src/food").default;    
food.mockImplementation(realFood);

describe("meal tests", () => {
  beforeEach(() => {
    jest.resetModules();
  });

  it("should print dinner", () => {
    expect(getMeal()).toBe(
      "Good evening. Dinner is green beans and rice. Yum!"
    );
  });

  it("should print breakfast (mocked)", () => {
    food.mockReturnValueOnce({ 
        type: "breakfast",
        veg: "avocado",
        carbs: "toast"
    });

    // ...this works now
    expect(getMeal()).toBe("Good morning. Breakfast is avocado and toast. Yum!");
  });
});

Of-course there are other options like splitting the test into two modules where one file sets up a mock and the other one uses a real module or returning a mutable object in place of a default export for the food module so it can be modified by each test and then manually reset in beforeEach.

Jest is installed, but is likely in your ./node_modules/.bin directory. You can append that to your command ./node_modules/.bin/jest --updateSnapshot. Since you already have jest as a scripts command in your package.json you can also run it with npm test -- --updateSnapshot. npm automatically adds ./node_modules/.bin to your path.

update: Newer versions of yarn will resolve node module bin scripts, so you can also just run yarn jest {cmd} and it should work.

Lately I find that I don't need babel-jest at all, and can get by simply with @babel/preset-env, and the following .babelrc:

{
  "env": {
    "test": {
      "presets": [["@babel/preset-env"]]
    }
  }
}

Short answer: don't.

Testing an internal state variable very much goes against the philosophy behind react-testing-library. That lib is focused on the user, and what the user can see. The user has no concept of a state variable. Instead of testing that, think of the changes the user would see, and test for that. How is the UI updated? What different markup or styling is displayed? Consider how to test from the user's perspective, and you'll find your answers.

Check out react-testing-library's Guiding Principles for more context. Then take a look through this page for guidelines on which queries make the most sense for your use case.

None of these worked for me, but I found a great article on configuring dotenv by default in Jest in the package.json:

{
  "scripts": {
    "test": "jest --setupFiles dotenv/config"
  }
}

The timeout you specify here needs to be shorter than the default timeout.

The default timeout is 5000 and the framework by default is jasmine in case of jest. You can specify the timeout inside the test by adding

jest.setTimeout(30000);

But this would be specific to the test. Or you can set up the configuration file for the framework.

Configuring Jest

// jest.config.js
module.exports = {
  // setupTestFrameworkScriptFile has been deprecated in
  // favor of setupFilesAfterEnv in jest 24
  setupFilesAfterEnv: ['./jest.setup.js']
}

// jest.setup.js
jest.setTimeout(30000)

See also these threads:

setTimeout per test #5055

Make jasmine.DEFAULT_TIMEOUT_INTERVAL configurable #652

P.S.: The misspelling setupFilesAfterEnv (i.e. setupFileAfterEnv) will also throw the same error.

Add this in your package.json jest config.

"transform": {
      "\\.js$": "<rootDir>/node_modules/babel-jest"
    },

Let me know if the issue still persists.

Had to add this to my jest key inside of package.json

Thanks to @Burimi for helping me debug, this setups a default global

"jest": {
  "globals":{
    "google": {
    }
  }
  ...