When mocking an ES module, one of the following two statements must be true:
the module reference can be resolved to an existing ES module, or
the module reference cannot be resolved to an existing ES module.
Examples of scenario one:
import foo from './relative/file.js' where ./relative/file.js refers to an existing file on the filesystem at that relative path and where that module has a default export
import { thing } from 'npm-package'; where npm-package can be resolved using Node's module resolution algorithm and where that package exports thing
If the module resolution algorithm cannot resolve the mock reference, then the mock falls into scenario two. This might happen if, for example, an LWC references a @salesforce scoped module that is only present when running on the Salesforce platform.
In scenario two, you can declare whatever mocks that you expect would be present on platform. For example, a component might have the following code:
import getTimeZone from '@salesforce/schema/UserInfo.getTimeZone';
In a test file, this might be mocked like so:
import timeZoneMock from 'mock{default}:@salesforce/schema/UserInfo.getTimeZone';
In other words, if the module reference is not resolvable, it is up to the test-author to ensure that the mocks are sufficient for their consumption in component code.
However, if the module reference is resolved correctly (scenario one), the system currently requires that the test author mock all exports in that resolved module. For example, if the real ES module exported default and somethingElse, the corresponding mock would have to be declared like so: import mock from 'mock{default,somethingElse}:...';.
This shouldn't be required. It should be possible to only mock default or somethingElse, and the non-mocked exports should be importable as normal.
When mocking an ES module, one of the following two statements must be true:
Examples of scenario one:
import foo from './relative/file.js'where./relative/file.jsrefers to an existing file on the filesystem at that relative path and where that module has a default exportimport { thing } from 'npm-package';wherenpm-packagecan be resolved using Node's module resolution algorithm and where that package exportsthingIf the module resolution algorithm cannot resolve the mock reference, then the mock falls into scenario two. This might happen if, for example, an LWC references a
@salesforcescoped module that is only present when running on the Salesforce platform.In scenario two, you can declare whatever mocks that you expect would be present on platform. For example, a component might have the following code:
In a test file, this might be mocked like so:
In other words, if the module reference is not resolvable, it is up to the test-author to ensure that the mocks are sufficient for their consumption in component code.
However, if the module reference is resolved correctly (scenario one), the system currently requires that the test author mock all exports in that resolved module. For example, if the real ES module exported
defaultandsomethingElse, the corresponding mock would have to be declared like so:import mock from 'mock{default,somethingElse}:...';.This shouldn't be required. It should be possible to only mock
defaultorsomethingElse, and the non-mocked exports should be importable as normal.