-
-
Notifications
You must be signed in to change notification settings - Fork 6.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
support async module mocking #9299
Comments
We can only support async mocks for ESM, as CJS is synchronous. In your case I'd create a separate file that exports an async function and await (and possibly mock) that instead of having a module with side effects. Mock of ESM modules (which will support promises) will come in #10976, you can track that |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
馃殌 Feature Proposal
In addition to the function-initializer style of
jest.mock
, support an async variant that accepts a function which returns a promise, and use the resolution from that promise to determine the mocked module's exports:Motivation
Some information that can be known statically or synchronously in applications is only available asynchronously in test cases. To ease development in this case, we could let the module initializer function be asynchronous to avoid problematic hacks. See workaround in
Pitch
section.Additionally, the
import
statement isn't a supported statement within the normal module initializer function, and tools like babel refuse to transpile it.Example
(the same as in
馃殌 Feature Proposal
)Pitch
Because this isn't a problem easily solved in the wild world of community ecosystem and support. There are fragile and application-specific ways to work around this problem by altering the application code itself in service to the tests, or by monkey patching external dependencies to make them work asynchronously. This is one such approach to working around this:
Moreover, it simplifies the adoption of
import
overrequire
for groups that prefer the former, as tools likebabel
don't support placing a standardimport
statement in the mocked function (babel/babel#10864).The text was updated successfully, but these errors were encountered: