[Feature] Number of expected assertions

[jhnns]

I think it is very useful to test for a number of assertions because in asynchronous tests it's a common error that callbacks are accidentally invoked multiple times.

Maybe this way:

expect(someValue).to.be.ok();
expect(someOtherValue).to.be.ok();

expect.numOfTests().to.be(2);

An internal counter counts the number of assertions. numOfTests() just matches the counter with the expected number. After numOfTests() is called the internal counter is reset.

One problem of that approach would be if testing suites run asynchronous tests in parallel. But I'm not sure if that is usual.

What do you think?

[nathanmacinnes]

The problem I see is that you'd have to manually reset it if you hadn't used it in a few test cases. Where you are using separate assertion and test libraries, I think a better way of monitoring the number of times a callback is called is with a counter in the callback, or with a decent mocking framework.

[skeggse]

The problem I see is that you'd have to manually reset it if you hadn't used it in a few test cases. Where you are using separate assertion and test libraries, I think a better way of monitoring the number of times a callback is called is with a counter in the callback, or with a decent mocking framework.

Yep. Another option would be to integrate a lightweight spy, like in Jasmine or Sinon. Personally, I like this option better, because it gives you more control.