readme: add note about uncaught exceptions #918
Conversation
|
I'm not sure this is the correct behavior. We may just want to run |
Uncaught exceptions cause the worker to be torn down. That seems reasonable to me. The behavior is somewhat similar to |
| @@ -433,7 +433,7 @@ test.failing('demonstrate some bug', t => { | |||
|
|
|||
| AVA lets you register hooks that are run before and after your tests. This allows you to run setup and/or teardown code. | |||
|
|
|||
| `test.before()` registers a hook to be run before the first test in your test file. Similarly `test.after()` registers a hook to be run after the last test. Use `test.after.always()` to register a hook that will **always** run once your tests and other hooks complete. `.always()` hooks run regardless of whether there were earlier failures, so they are ideal for cleanup tasks. | |||
| `test.before()` registers a hook to be run before the first test in your test file. Similarly `test.after()` registers a hook to be run after the last test. Use `test.after.always()` to register a hook that will **always** run once your tests and other hooks complete. `.always()` hooks run regardless of whether there were earlier failures, so they are ideal for cleanup tasks. **Note**: In the case of uncaught exceptions, `test.after.always()` will not be called. | |||
There was a problem hiding this comment.
I would rephrase this though:
… they are ideal for cleanup tasks. There are two exceptions to this however. If you use
--fail-fastAVA will stop testing as soon as a failure occurs, and it won't run any hooks including the.always()hooks. Uncaught exceptions will crash your tests, possibly preventing.always()hooks from running.
There was a problem hiding this comment.
Uncaught exceptions will crash your tests, possibly preventing .always() hooks from running?
There was a problem hiding this comment.
I'm not familiar with the internals, but are there cases where uncaught exceptions will allow .after to run?
There was a problem hiding this comment.
Yes, if they occur after .after has run. With asynchronous tests it's a race between a test completing and an uncaught exception occurring.
|
Updated to new wording. |
|
LGTM 😉 |
|
LGTM, because it reflects reality. Though, I'm not totally happy about |
I usually get around that with
What if we allowed a Or what if we allowed an test.before.and.after(fn)
test.beforeEach.and.after.always(fn) |
|
@jamestalmage Can you move the bottom part of your comment to a new issue? |
fixes issue #917