Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ability to check the exact number of assertion calls per-test #102

Closed
bompus opened this issue Sep 19, 2021 · 6 comments
Closed

Add ability to check the exact number of assertion calls per-test #102

bompus opened this issue Sep 19, 2021 · 6 comments
Assignees

Comments

@bompus
Copy link
Contributor

bompus commented Sep 19, 2021

Over the years, with various test runners / assertion libraries, I've encountered several false-passing tests due to assertions inside of async / promise resolutions, callbacks, and mocks not actually executing.

The only test runner that I'm aware of which has this check built-in is Jest with expect.assertions(number).

Developers have requested this feature of other libraries (7-year long chai issue/discussion) , but most have not come up with an eloquent way to handle it.

@bompus
Copy link
Contributor Author

bompus commented Sep 19, 2021

I believe this can eloquently be handled by Zora, using either the test() expectAssertions option proposed in PR #103 or by some other means, but the end goal can be achieved easily because Zora stores assertion results as an array already, instead of throwing, making it easier to add features like this.

@lorenzofox3
Copy link
Owner

It is actually implemented in AvA and Tape too (under .plan()). Although that 's kind for legacy reasons, when node was all CPS (continuous passing style). Nowadays with new control flows (such ascync/await) I find very few usage of it. See the take of AvA on the topic.

Do you have concrete examples to share where you feel it really has an added value ?

@bompus
Copy link
Contributor Author

bompus commented Sep 23, 2021

I actually solved it in userland yesterday while playing around in mocha/chai/expect on another project. The (weird) but valid example can also be seen at chaijs/chai#94 (comment)

@lorenzofox3
Copy link
Owner

Yes that is what I thought. Usually for this kind of legacy code, I simply test on side effects:

test('check callback error', async (t) => {
    let error;
    
    await promiseCbAsync(badFnAsync(), (err, rtn) => {
      error = err
    });
  
    t.eq(error?.message, 'expectedErrorMessage')
})

@lorenzofox3
Copy link
Owner

So I close this for now

@bompus
Copy link
Contributor Author

bompus commented Sep 23, 2021

Yes, right after I sent the last reply and thought about it some more, just assign something a variable inside the callback, then assert it after the await.

Consider this closed, as the example you posted back is both much simpler and easier for folks to understand looking at the test.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants