Skip dependent steps when a prior step fails

[dotnetprofessional]

Problem

When a step fails in a scenario, subsequent steps still execute even though they have no chance of passing. This wastes time — especially in UI automation where steps can be slow — and clutters output with cascading failures.

Current Behavior (Vitest)

Each step is registered as an independent Vitest task. When a step throws, the error is re-thrown but remaining steps in the scenario still execute. There is no scenario-level execution context that can conditionally skip remaining steps.

Proposed Behavior

Skip dependent steps based on Gherkin semantics:

• \given\ fails → execute remaining \given\ steps (to see what's broken), skip all \when\ and \ hen\
• \when\ fails → skip remaining \when\ steps, skip all \ hen\
• \ hen\ fails → continue executing remaining \ hen\ steps (they're typically fast assertions)

Skipped steps should be reported with a \skipped\ status (not \pending\ or \ail) and the reason for skipping.

Technical Notes

• Vitest's task model doesn't natively support conditional skipping of registered tasks at execution time
• Would need a scenario-level execution tracker that steps check before running
• The xUnit version doesn't need this — C# sequential method execution naturally aborts on exception

[Lautenschlager-id]

This is a highly needed feature for this project! Is this still active or has it been abandoned?

[dotnetprofessional]

Are you actively using the library in your projects?

[Lautenschlager-id]

I'm actually considering to migrate from mocha-cakes-2 to this, but this issue seems to be one of the only things stopping this migration now. Would you not recommend using LiveDoc anymore?

[Lautenschlager-id]

I've made this small plug-in to address this issue: https://gist.github.com/Lautenschlager-id/a85a3a2791b7f210d39d5983edd49b2b

It's a bit too high level to be implemented in the source of this lib, but it's one step forward for migrating my system :P (or not)

[dotnetprofessional]

Nice, the tests you have seem to match what we'd want. It's been a while since I looked at/worked on the code, as I don't do a lot of JS/TS development today. As to whether you should use it, I really liked the library when I was using it, and if you're using mocha-cake2 this is much more advanced, and the custom UI is nice. You can also write your own fairly easily. I may not be able to offer much support, but it was extensively tested at the time it was written and its fairly well tested (automated).

The last time I did try it, though, I noticed the mocha had changed, and it would need an update to be more compatible with the later versions. If this isn't causing you any issues, then it's a better option than the alternative. I think mocha-cakes-2 has been unsupported for some time too, last updated 5yrs ago.

P.S: Happy to take PRs :)

[Lautenschlager-id]

Cool! I don't really plan on using the custom UI, even though it's indeed nice. I'll let my team have a say as well on migrating, and if anything it would be farily easy to rollback considering cakes-2 is very similar to this. It's been working fine on my system, so I believe mocha changes haven't affected your lib. But I'll make sure to open an issue here if we find one, even if you don't plan to support it anymore, it'd be nice for others considering to use it hehe Thanks for the replies anyway ;)

[dotnetprofessional]

Sounds good - though do at least check out the non-stock UI I built, even has source map translation if you happen to use TS in the error messages (may even be clickable). If you do see an issue, do post, I'll take a look.