Provide an API to flush the Promise resolution queue

**Do you want to request a *feature* or report a *bug*?** _Feature_, I guess, but a pretty important one when testing code that uses `Promise`s. **What is the current behavior?** I have a component that uses `Promise` wrapping and chaining internally in the follow-up to an external asynchronous action. I'm providing the mock of the async action and resolving the promise it returns in my test. The component something like this: ```jsx class Component extends React.Component { // ... load() { Promise.resolve(this.props.load()) .then( result => result ? result : Promise.reject(/* ... */) () => Promise.reject(/* ... */) ) .then(result => this.props.afterLoad(result)); } } ``` And the test code looks something like this: ```javascript const load = jest.fn(() => new Promise(succeed => load.succeed = succeed)); const afterLoad = jest.fn(); const result = 'mock result'; mount(<Component load={load} afterLoad={afterLoad} />); // ... some interaction that requires the `load` load.succeed(result); expect(afterLoad).toHaveBeenCalledWith(result); ``` The test fails because the `expect()` is evaluated before the chained promise handlers. I have to replicate the length of the inner promise chain in the test to get what I need, like this: ```javascript return Promise.resolve(load.succeed(result)) // length of the `.then()` chain needs to be at least as long as in the tested code .then(() => {}) .then(() => expect(

Posted by hon2a on Nov 23, 2016, 5:00 PM

Tags

• github (Other)

Related issues

• struct's lifetime requirements can be bypassed via covariant field assignment
• Proposal to Reorganize the Moderation Team and Review Moderation Policies
• Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
• proposal: container/...: generic collection types
• Better Custom Endpoint BYOK
• A concrete policy for backward compatibility until Godot 5.0