wait for the event queue to drain before starting the next step

[kevgo]

In order to support asynchronous clean-up better, and increase overall robustness of the framework, it would be useful if CucumberJS would start the next scenario only after waiting for the event queue to drain. What this means is do a setTimeout <continue>, 0 before running the next scenario. This gives any queued up asynchronous cleanup jobs from the previous scenario time to run before Cucumber starts with the next scenario.

[charlierudolph]

Can you please give an example? I'm curious why asynchronous cleanup jobs that aren't performed in after hooks.

[kevgo]

I have test code that makes network calls. My tests properly waits for the response to the call, and my SUT sends out the response only when it is done processing the request. So everything should be golden.

And it works fine. Sometimes, however, these calls get processed after the next scenario step is already running. I have no clue why this happens.

The solution to this is to add a "setTimeout 0" step to the next test step that uses the result of the network call.

This out-of-order processing of events may be an issue of OS X, maybe it's Node, maybe its a bug in CucumberJS, or maybe its an issue with my code. In any case, I think adding additional bulkheads to compartmentalize different sequential activities (like scenario steps) more from each other is a good architectural pattern for Node apps. CucumberJS should provide that pattern to make it easy to write robust tests that aren't plagued by various edge cases around timing and the Node event queue. Just a useful best practice for such a framework imho.

[charlierudolph]

Your original request was only to do add a "setTimeout 0" after each scenario yet your use case appears to asking for it after each step. Please clarify.

Also having a "setTimeout 0" is only useful if an asynchronous operation has already completed and is waiting for a chance to trigger its callback. We aren't actually waiting for all stray asynchronous operations, which is what I think you are trying to solve. To me this solution actually has the potential to hide timing errors as you are relying on something completing in another event loop instead of explicitly waiting for it to complete.

[kevgo]

I'm proposing to wait for the next event loop iteration before starting the next step (I have fixed the issue title). The proper method for that seems setImmediate. Running it before each scenario allows any pending IO currently queued up in the event queue to be processed before starting the next step.

I agree that doing so hides timing errors in the test code. This is the whole point of the bulkhead pattern: to provide additional robustness against edge cases, so that the developer doesn't have to obsess about getting all the different timing issues right, and prevent timing issues from affecting other parts of the test suite.

[mete89]

I have similar problem. I'm using request module for checking some resources on CDN. Mostly, it skips result of promise and continue with next case.

What is the proper way of using async calls in cucumber.js?

[charlierudolph]

@kevgo I'm going to close this as I disagree with the need for this. I really don't like the idea of writing a test to ensure this happening as it would make something work that I don't think should.

@mete89 ensure you return the promise if you want cucumber to wait for it complete. Docs. I'll add a comments making it more clear the return is necessary

[kevgo]

Fine with me, I don't feel strongly about it. :)

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.