Jesper van den Ende

Ah good idea, that would sort of work, but I'd like the unit test suite to still run because those tests might give further insights in what is going wrong....

> You can use this to conditionally start the next step only if the first one succeeded. That's what I'm doing in the wrapper function in the first comment :)...

Yeah exactly, a wrapper function wouldn't be possible and you'd have to wrap every step in a separate if statement. Also the nice thing about asserting is that you can...

Oh hah, nice! Though to add some more context. In the e2e tests I have some helper functions that perform common tasks inside a separate step. Something like: ```js async...

I'd like to have a go at this.

Ah I see, I thought this would require the wrapper to be added to every step, but I realise now that the wrapper could simply add itself to sub steps.

I couldn't help myself and tried to see what an implementation in Deno would look like: https://github.com/denoland/deno/pull/15285 I remember now the problem with a wrapper is that the thrown error...

Ah I see, I guess I was too focused on propagating the error xD The only difference then, is that the final errors section doesn't contain the actual error, but...

When using `assert` in heavily nested steps, the output looks like this:  The proposed option propagates the option down to subtests, and ensures the thrown error automatically propagates up...

With `throwOnError` only the initial error is logged, as can be seen in the [screenshot from the PR](https://github.com/denoland/deno/pull/15285):  Removing useless stack frames would certainly help too, I'm not sure...