This would be useful for API integrators who want more control for when to back out of the test run, and do so in a graceful way.
It could also be used by our CLI to e.g. watch for the Ctrl+C signal and gracefully end the test run after the current step so there are still usable reports.
✨ What's your proposed solution?
It would make sense to lean into web features for this - AbortSignal is supported in browsers, Deno and Node.js and would be a familiar pattern to many. So one of the arguments to runCucumber could include an optional cancelSignal prop.
⛏ Have you considered any alternatives or workarounds?
Do nothing is an alternative.
📚 Any additional context?
We'd need to figure out some details about what the behaviour should be when you cancel:
Let the current step finish and mark the rest of the test case as skipped?
What about the remaining test cases? Should they be skipped or unknown?
Should AfterEach hooks run? After? AfterAll? (I would say yes to the first and no to the second two)
What (if any) are the implications for the parallel runtime?
Would we need to make any changes to formatters to support this? Would we need a way to represent it in Cucumber messages?
🤔 What's the problem you're trying to solve?
A few times the concept of cancelling/aborting a test run has come up:
This would be useful for API integrators who want more control for when to back out of the test run, and do so in a graceful way.
It could also be used by our CLI to e.g. watch for the Ctrl+C signal and gracefully end the test run after the current step so there are still usable reports.
✨ What's your proposed solution?
It would make sense to lean into web features for this - AbortSignal is supported in browsers, Deno and Node.js and would be a familiar pattern to many. So one of the arguments to
runCucumber
could include an optionalcancelSignal
prop.⛏ Have you considered any alternatives or workarounds?
Do nothing is an alternative.
📚 Any additional context?
We'd need to figure out some details about what the behaviour should be when you cancel:
AfterEach
hooks run?After
?AfterAll
? (I would say yes to the first and no to the second two)This text was originally generated from a template, then edited by hand. You can modify the template here.