-
Notifications
You must be signed in to change notification settings - Fork 7.6k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This PR adds a page on how to mock the scheduler, as a companion to facebook/react#16207. (Most people won't see this, since nobody's using concurrent/sync modes yet.)
- Loading branch information
1 parent
1d8e542
commit ebd49d3
Showing
1 changed file
with
23 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,23 @@ | ||
--- | ||
id: mock-scheduler | ||
title: Mocking the scheduler | ||
permalink: docs/mock-scheduler.html | ||
--- | ||
|
||
Mocking the scheduler for tests can guarantee consistent behaviour across modes. | ||
|
||
React uses the `scheduler` module to sequence how and when 'work' get queued and executed in time. While this behaviour varies across modes, we still want to write tests that are decoupled from the mode they are running in. To make tests run consistently across modes, we can use [module mocking](/docs/testing-recipes.html#mock-modules) to mock `scheduler` with a test friendly version `scheduler/unstable_mock`. Combined with `act()`, you should be able to write tests that run consistently across modes. | ||
|
||
### Setup | ||
|
||
For jest, we can setup the mocked scheduler by adding this line before any other imports in a test suite, or adding it to a [global configuration file](https://jestjs.io/docs/en/cli#config-path). | ||
|
||
```jsx | ||
jest.mock("scheduler", () => require("scheduler/unstable_mock")); | ||
``` | ||
|
||
|
||
* In environments that don't support module mocks, we could still (with some effort) setup the builds for tests such that the scheduler is replaced with the mock version. | ||
* While not mocking the scheduler means that we can't guarantee the order and timing of updates to the rendering surface, this might not be a problem for certain classes of tests like end-to-end tests, etc. | ||
|
||
|