You can mock non defaults like this:

jest.mock('a-module', () => ({
  __esModule: true,
  default: () => 'Blah',
  A: () => 'Blah',
  B: () => 'Blah'
}));

https://remarkablemark.org/blog/2018/06/28/jest-mock-default-named-export/

or use __mocks__

as an alternative you could create a file under __mocks__ folder next to the original module with the same name as the module:

a_module_folder > 
    a-module.js
    __mocks__ >
        a-module.js

and that mock should just export the mocked versions:

export const A = () => 'Blah';
export const B = () => 'Blah';

and then just mock like this:

jest.mock('a-module');

for node_modules just put __mocks__folder on the same level as node_modules

https://jestjs.io/docs/en/manual-mocks

The other suggestions in this thread would cause errors on my end, where any tests with process.exit would run indefinitely. The following option worked for me on TypeScript, but it should work on JavaScript as well:

const mockExit = jest.spyOn(process, 'exit').mockImplementation(() => {});
myFunc(condition);
expect(mockExit).toHaveBeenCalledWith(ERROR_CODE);

The catch is that simply using spyOn meant that the original process.exit() function was still called, ending the process thread and hanging tests. Using mockImplementation at the end replaces the function body with the provided function (which is empty in my example).

This trick is also useful for tests that print to, say, stdout. For example:

const println = (text: string) => { process.stdout.write(text + '\n'); };
const mockStdout = jest.spyOn(process.stdout, 'write').mockImplementation(() => {});
println('This is a text.');
expect(mockStdout).toHaveBeenCalledWith('This is a text.\n');

This will let you test printed values, and have the added benefit of not messing up CLI console output with random linebreaks.

Just one note: As with any "jest.spyOn" call, regardless of using mock implementation or not, you need to restore it later on in order to avoid weird side-effects of lingering mocks. As such, remember to call the two following functions at the end of the current test case:

mockExit.mockRestore()
mockStdout.mockRestore()

So I solved the issue by abstracting all the app logic to an app.js file:

const express = require('express');
const routes = require('./routes');
const app = express();

app.use('/api', routes);

module.exports = app

Then creating a server.js file with all my server logic:

const app = require('./app.js')
const PORT = process.env.PORT || 3000
app.listen(PORT, () => console.log(`Listening on port: ${PORT}`))

Then just import app.js into your test file like this:

const app = require('../app.js')

Works like a charm!

Error constructor doesn't expect {status: number} to be passed to it. You can create and use custom error class:

class CustomError extends Error {
    status: number;

    constructor(message: string, { status }: { status: number }) {
        super(message);
        this.status = status
    }
}

// ...

throw new CustomError('Error Message', { status: 403 })

Or you could assign status property to the error after creation:

throw Object.assign(new Error('Error Message'), { status: 403 })

Your import and export syntaxes do not match. You'll need to change one or the other for this to work. If you want to use the default export, eg:

export default class MyClass { ... }

Then the corresponding import is:

import MyClass from '../src/myclass.js'

Or if you'd like to continue using the same import syntax, then remove the 'default' when exporting:

export class MyClass { ... }

Then:

import { MyClass } from '../src/myclass.js'

The problem

The reason you're getting that error has to do with how various operations are hoisted.

Even though in your original code you only import SearchContainer after assigning a value to mockSearch and calling jest's mock, the specs point out that: Before instantiating a module, all of the modules it requested must be available.

Therefore, at the time SearchContainer is imported, and in turn imports search , your mockSearch variable is still undefined.

One might find this strange, as it would also seem to imply search.js isn't mocked yet, and so mocking wouldn't work at all. Fortunately, (babel-)jest makes sure to hoist calls to mock and similar functions even higher than the imports, so that mocking will work.

Nevertheless, the assignment of mockSearch, which is referenced by the mock's function, will not be hoisted with the mock call. So, the order of relevant operations will be something like:

1. Set a mock factory for ./search.js
2. Import all dependencies, which will call the mock factory for a function to give the component
3. Assign a value to mockSearch

When step 2 happens, the search function passed to the component will be undefined, and the assignment at step 3 is too late to change that.

Solution

If you create the mock function as part of the mock call (such that it'll be hoisted too), it'll have a valid value when it's imported by the component module, as your early example shows.

As you pointed out, the problem begins when you want to make the mocked function available in your tests. There is one obvious solution to this: separately import the module you've already mocked.

Since you now know jest mocking actually happens before imports, a trivial approach would be:

import { search } from './search.js'; // This will actually be the mock

jest.mock('./search.js', () => {
  return { search: jest.fn(() => mockPromise) };
});

[...]

beforeEach(() => {
  search.mockClear();
});

it('should call the search module', () => {
  [...]

  expect(search.mock.calls.length).toBe(1);
  expect(search.mock.calls[0]).toEqual(expectedArgs);
});

In fact, you might want to replace:

import { search } from './search.js';

With:

const { search } = require.requireMock('./search.js');

This shouldn't make any functional difference, but might make what you're doing a bit more explicit (and should help anyone using a type-checking system such as Flow, so it doesn't think you're trying to call mock functions on the original search).

Additional note

All of this is only strictly necessary if what you need to mock is the default export of a module itself. Otherwise (as @publicJorn points out), you can simply re-assign the specific relevant member in the tests, like so:

import * as search from './search.js';

beforeEach(() => {
  search.search = jest.fn(() => mockPromise);
});

Run jest --coverage command to check coverage

TL;DR

Indeed ES import statements import default and import * are not the same thing, the fact that they behave the same in this case is a combination of how React authors chose to publish the library and compatibility layers in TypeScript (using esModuleInterop) or Babel and your bundler to make them "just work". It probably shouldn't work according to ES6 spec, but today we are still working in an era where JS modules are a mess, so tools like Babel, TypeScript, Webpack, etc try to normalize behavior.

More details:

React is not an ES6 library. If you look at the source code you see this in index.js:

const React = require('./src/React');

// TODO: decide on the top-level export form.
// This is hacky but makes it work with both Rollup and Jest.
module.exports = React.default || React;

(Note the comment, even in React source code they struggle with ES6 default export compatibility.)

The module.exports = syntax is CommonJS (NodeJS). A browser would not understand this. This is why we use bundlers like Webpack, Rollup, or Parcel. They understand all kinds of module syntax and produce bundles that should work in the browser.

But even though React is not an ES library, both TypeScript and Babel let you import it as if it is (using import syntax, rather than require(), etc), but there are differences between CJS and ES that have to be resolved. One of them is the fact that export = can give you things that ES has no spec-compliant way to import, like a function or a class as the module. To work around these incompatibilities Babel has for awhile allowed you to import CJS modules as if they were exporting something by default, or import as a namespace. TypeScript for awhile didn't do this, but more recently added that as an option under esModuleInterop. So now both Babel and TypeScript can pretty consistently allow a CJS module to be imported using default or namespace ES imports.

With TypeScript it also depends on how the type-definitions for the library are actually defined. I won't get into that, but you can imagine situations where thanks to transpilers and bundlers a particular import works at runtime, but TypeScript doesn't compile without errors.

Another thing worth mentioning is that if you look at the built code for React there is a UMD module version as well as the CJS version. The UMD version includes some gnarly runtime code to try to make it work in any module environment, including the browser. It's mainly for use if you want to just include React at runtime (ie you don't use a bundler). Example.

Confusing? Yeah, I think so. :)

You need to use jest.mock() to mock mailgun-js module.

E.g.

mailgun.ts:

import mg from 'mailgun-js';

// Get database name from configuration file
const mailgunConfig: mg.ConstructorParams = {
  apiKey: '123',
  domain: 'example.com',
};

// Setup Mailgun Service
const mailgun = mg(mailgunConfig);

// Mailgun Service class
export class Mailgun {
  /**
   * Static function to send an email.
   * @param {mg.messages.SendData} emailParams - parameters to sent an email.
   * @returns {Promise<mg.messages.SendResponse>} - maligun response with message and id.
   */
  static sendEmail = (emailParams: mg.messages.SendData): Promise<mg.messages.SendResponse> => {
    return mailgun.messages().send(emailParams);
  };
}

mailgun.test.ts:

import { Mailgun } from './mailgun';
import mg from 'mailgun-js';

jest.mock('mailgun-js', () => {
  const mMailgun = {
    messages: jest.fn().mockReturnThis(),
    send: jest.fn(),
  };
  return jest.fn(() => mMailgun);
});

// sendEmail Test Suite
describe('Send Email', () => {
  it('returns the promise of queued object with id and message keys when valid email is passed', async () => {
    // Preparing
    const emailParam = {
      from: 'noreply@shop.techardors.com',
      to: 'ecomm@api.com',
      subject: 'TechArdors Shopping: One-time passcode to reset the password',
      html:
        '<p>Please enter the passcode <strong>5124</strong> to reset the password. It expires in 5 minutes from the time it is requested.</p>',
    };
    const mailgun = mg({} as any);
    (mailgun.messages().send as jest.MockedFunction<any>).mockResolvedValueOnce({
      id: '222',
      message: 'Queued. Thank you.',
    });
    // Executing
    const result = await Mailgun.sendEmail(emailParam);
    // Verifying
    expect(result.message).toBe('Queued. Thank you.');
    expect(result).toHaveProperty('id');
    expect(result).toHaveProperty('message');
    expect(mailgun.messages).toBeCalled();
    expect(mailgun.messages().send).toBeCalledWith(emailParam);
  });
});

Unit test result with coverage report:

 PASS  src/stackoverflow/59463875/mailgun.test.ts (7.587s)
  Send Email
    ✓ returns the promise of queued object with id and message keys when valid email is passed (7ms)

------------|----------|----------|----------|----------|-------------------|
File        |  % Stmts | % Branch |  % Funcs |  % Lines | Uncovered Line #s |
------------|----------|----------|----------|----------|-------------------|
All files   |      100 |      100 |      100 |      100 |                   |
 mailgun.ts |      100 |      100 |      100 |      100 |                   |
------------|----------|----------|----------|----------|-------------------|
Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        8.723s

Source code: https://github.com/mrdulin/jest-codelab/tree/master/src/stackoverflow/59463875