Mocking
Mocking lets you replace dependencies in tests, control return values, and assert how functions or modules are called. Rstest provides different mocking APIs for functions, object methods, ESM modules, CommonJS modules, and object trees.
Mock modules
If a dependency is loaded through the module system, you can choose different APIs based on the module type and mocking behavior.
Mock ESM modules
If a dependency is loaded through import, you can use rstest.mock() or rstest.doMock().
Use rstest.mock()
rstest.mock() is hoisted to the top of the file. It is useful when the dependency should be replaced before the module under test runs.
Use rstest.doMock()
Note that rstest.doMock() is not hoisted and only takes effect after it runs. It is useful when earlier import statements should keep the real implementation and later ones should use the mock.
Mock CommonJS modules
If a dependency is loaded through require(), you can use rstest.mockRequire() or rstest.doMockRequire().
Use rstest.mockRequire()
rstest.mockRequire() is hoisted to the top of the file. It is useful for file-level mocking of CommonJS modules.
Use rstest.doMockRequire()
Note that rstest.doMockRequire() is not hoisted and only affects later require() calls.
Note that this distinction matters when a package exposes both ESM and CommonJS entries. Mocking the ESM entry does not automatically affect the CommonJS entry, and vice versa.
Auto-mock modules
If you want to replace the module's function exports with mock functions first and then configure only selected exports in the test, you can use { mock: true }.
Spy on a whole module
If you want to keep the real implementation and still assert calls, you can use { spy: true }.
Partially mock modules
If you want one export to keep the real implementation and another export to be replaced, you can use importActual.
Note that factory functions are hoisted, so they should not read values that are initialized later in the same file.
Reuse manual mocks from __mocks__
If multiple tests reuse the same fake implementation, you can place it in __mocks__ and load it without passing a factory.
Reset module state
If you want later import or require() calls to return the original module again, you can use these APIs:
- rstest.unmock() / rstest.doUnmock(): stop mocking a module.
- rstest.resetModules(): clear the module cache so the next import or require evaluates the module again.
Note that rstest.resetModules() does not cancel module mocking. To cancel module mocking, use rstest.unmock() or rstest.doUnmock().
For the full API and more examples, see Mock modules.
Mock functions
If a dependency is passed in as a callback or injected implementation, you can use rstest.fn() to create a mock function.
You can also override behavior through mock instance methods, for example by returning a different value for one call:
For the full API and more examples, see Mock functions and MockInstance.
Spy on existing methods
If you want to keep the real object and still track calls or temporarily override behavior, you can use rstest.spyOn().
This pattern is commonly used with globals such as console and Date, as well as shared objects that already exist in the test.
Deep-mock objects
If a dependency already exists in memory and you want to convert nested methods into mocks, you can use rstest.mockObject().
If you want to keep the original nested implementations while still recording calls, you can pass { spy: true }.
For the full API and more examples, see Mock functions and MockInstance.
Clear mock state
If you need to clear call history or reset mock implementations, you can use these APIs:
- clearMocks: clear call history before each test.
- resetMocks: clear call history and reset mock implementations.
- restoreMocks: restore spied descriptors on real objects.
For manual cleanup, the corresponding APIs are rstest.clearAllMocks(), rstest.resetAllMocks(), and rstest.restoreAllMocks().