Emit error when there are more assertions than planned about ava HOT 9 CLOSED

We do emit an error when the assertion count doesn't match planned. Why do we need the _pendingAsserts in the first place?

I have probably misunderstood this bug, can you please clarify? @kevva

from ava.

@mdibaiee I think it's related to this: https://github.com/sindresorhus/ava/blob/ff5eebba5d06ea22a1ed1ca5f76f33386bee8381/test/test.js#L245-L247

from ava.

@sindresorhus: I see, I'll take a look to see if I can fix this when I get some free time.

from ava.

If I'm understanding this correctly, the way I've seen it done before is even if t.end() has been called and the test passed, an assertion called after that point will re-show the test as failed. You don't need to know the point of last assertion, and you will never know thanks to the halting problem.

from ava.

@mdibaiee Did you have a chance to look into it? No worries if not :)

from ava.

@sindresorhus: Hey,

I took a look, couldn't find a solution, it might be possible if we have a timeout, but then, we can't just wait for the timeout to pass for every test only because it might be doing something wrong.

A funny idea hit my head! Inspecting the test body's code, searching for <first-argument>.assert and similar method calls 😆

from ava.

A funny idea hit my head! Inspecting the test body's code, searching for .assert and similar method calls 😆

Going to assume that was a joke 🆘

If things are blocking and async functions are still at play, node won't terminate. You don't have to wait for anything unless it's a faulty test.

from ava.

@Qix- yeah that was a joke.

How can we know if there are async functions still in progress? process._getActiveHandles() and process._getActiveRequests() only work for IO handles/requests.

from ava.

Because node won't terminate unless they're done executing.

from ava.