better support for assertion libraries

[Ciantic]

Mocha could have a simple way to plug in assertion counting, assertion libraries could then reset the counter on beginning of each test.

Default number of assertions could be guessed from simply searching "assert" or some other word provided by assertion library from within the string of the test content.

[danielstjules]

It's an interesting idea, but I think it imposes too rigid of a structure on the way someone writes their tests. For example, I might write a test that makes 0 use of assertions, but throws an exception given some behavior.

Furthermore, assertion functions can be mapped to non-standard names. var foo = require('assert'); It would be difficult to enforce anything other than simple cases (looking for expect, assert and should) without a heavy implementation (parsing AST, etc).

[boneskull]

I would like this behavior, but perhaps not this implementation.

something like

describe('foo', function() {
  it('does stuff', function() {
    this.assertions(4);
    expect(foo).to.be(bar);
    expect(foo).to.be(bar);
    expect(foo).to.be(bar);
    expect(foo).to.be(bar);
  });
});

this is similar to nodeunit's implementation

[boneskull]

but I suppose the rub here is detecting assertions is difficult

[boneskull]

right, it's all coming back to me now. we discussed this in another ticket somewhere. if we want this behavior, we need to write adapters for assertion libraries. the assertion library would need to be "registered":

mocha.use(require('chai'));

if we're going to do that, we need to make it so people can write more adapters.

I don't see this as necessarily bad, as it'd give us the potential for more functionality around assertion libraries--but we can't expect assertion libraries to implement anything for us.

[boneskull]

anyway, this needs more thought. #1457

[danielstjules]

If we introduced a new API for registering assertion libs, we could cover some of the more popular libraries with adapters, and expose a generic adapter or adapter interface for others to work with.

[danielstjules]

Would there be other benefits to registering the assertion lib aside from assertion counting? Seems like a lot for only 1 feature. But if there's a few others, then it's prob worth the work.

[boneskull]

@danielstjules depends how full-featured the assertion library is! but agreed, this would be a lot for just one feature.

[papandreou]

Another benefit from registering the assertion lib would be the ability to make sure that the test doesn't get marked as passing when there are outstanding promises, as that indicates a missing return of a promise. At least this would be a great help for the unexpected assertion library, which uses promises internally to orchestrate asynchronous tests, and probably also chai-as-promised.

[Ciantic]

Enabling the guessing default number of assertions could be option given on the assertion library. It could do the heuristics when given a test function string.

In my test files it's not very nice to write this.assertions(n) at the beginning of each test, when all of the tests has exactly same number of assertions as simply searching "assert" from within a test function string.

[JoshuaKGoldberg]

anyway, this needs more thought. #1457

Indeed it does. Per #2044, I think this specific proposal is one we can close out. Having a plugin API such as in #1457 would be the right way to provide users the means to do this themselves.