You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
jest.mock('.../db.js',async()=>{// Where the import() is transpiled by babel - this is not a feature request for// import support.constMongoMemoryServer=awaitimport('mongo-memory-server'),mongoist=awaitimport('mongoist'),mongod=newMongoMemoryServer(),uri=awaitmongod.getConnectionString();returnmongoist(uri);});
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)
jest.mock('.../db.js',async()=>{// Where the import() is transpiled by babel - this is not a feature request for// import support.constMongoMemoryServer=awaitimport('mongo-memory-server'),mongoist=awaitimport('mongoist'),mongod=newMongoMemoryServer(),uri=awaitmongod.getConnectionString();returnmongoist(uri);});
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 over require for groups that prefer the former, as tools like babel don't support placing a standard import statement in the mocked function (babel/babel#10864).
The text was updated successfully, but these errors were encountered:
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.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.
🚀 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: