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

Create and implement async/sync test helpers #523

Merged
merged 1 commit into from
Oct 10, 2018

Conversation

MitMaro
Copy link
Contributor

@MitMaro MitMaro commented Sep 15, 2018

For #492

In #507 there was a comment about creating a utility function to help with testing both the asynchronous and synchronous calls to sign and verify. This is the concept that I came up with based on that comment. If this is accepted I will update the existing refactored tests to use the helpers.

Coverage Master

=============================== Coverage summary ===============================
Statements   : 97.87% ( 230/235 )
Branches     : 97.55% ( 199/204 )
Functions    : 100% ( 23/23 )
Lines        : 98.28% ( 228/232 )
================================================================================

Coverage Branch


=============================== Coverage summary ===============================
Statements   : 97.87% ( 230/235 )
Branches     : 97.55% ( 199/204 )
Functions    : 100% ( 23/23 )
Lines        : 98.28% ( 228/232 )
================================================================================

@MitMaro
Copy link
Contributor Author

MitMaro commented Sep 25, 2018

Hey @ziluvatar , just a friendly bump. I know pull requests can get lost in the weeds on GitHub.

Copy link
Contributor

@ziluvatar ziluvatar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delay :(

expect(err.message).to.equal('"iat" should be a number of seconds');
done();
signWithIssueAt(iat, {}, (err) => {
// the sign function swallows the error that is thrown by expect, so use done(err)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting, I didn't know about this, I guess it happens because of this:

callback = callback && once(callback);

We might tackle that at some point, for now, it's fine your handling here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I just checked our current async tests, if they fail they fail with error:
ensure "done()" is called (because as you said sign function swallows the throw error.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I assumed the existing tests would have the same issue. This is definitely something I would like to fix eventually, assuming someone else doesn't get to it first.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After looking into this in further detail, this would also be a problem is #511 was every addressed.

Long term introducing Promises would be a possible solution as it would properly handle errors thrown in an asynchronous context.

test/test-utils.js Show resolved Hide resolved
test/claim-iat.test.js Outdated Show resolved Hide resolved
@MitMaro MitMaro force-pushed the async-tests branch 2 times, most recently from fc7f484 to 731a76d Compare October 3, 2018 02:32
It is difficult to write tests that ensure that both the asynchronous
and synchronous calls to the sign and verify functions had the same
result. These helpers ensure that the calls are the same and return the
common result.

As a proof of concept, the iat claim tests have been updated to use the
new helpers.
expect(err.message).to.equal('"iat" should be a number of seconds');
done();
signWithIssueAt(iat, {}, (err) => {
testUtils.asyncCheck(done, () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a bit weird to use this, however, it is better than the try-catch, and more stable than simply... adding the asserts. So, good, let's keep this solution for now until we find a better one.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Long term, promises solves this problem and that appears to be direction that the JavaScript/Node.js community is moving. But that would mean converting the project to not use callbacks, which would be well outside the scope of fixing the tests.

function asyncCheck(done, testFunction) {
try {
testFunction();
done();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we want this call (done()) outside of the try to avoid double called in case of error inside of it, right? (because we are passing the done from mocha)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

^ Silly thing, I'm also fine if you leave it as is, just let me know and I'll merge.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both options have different problems.

The way the code is currently means that if the done() call throws an error then done(err) will be called. This would be a double call to done which is generally considered a bad practice. In the case of Mocha, it will warn about the double call to done. Also, in this case anyways, for done() to fail, it would mean that Mocha is broken in some way.

By moving the done() call outside the try block then an error thrown by done() could be swallowed and not reported by Mocha or logged to the console.

I decided on what is there now, because I would rather Mocha tell the developer that something went wrong, then ignoring the error, or reporting that done was not called.

I think it's fine to keep things this way and try to fix the library later to avoid this problem altogether.

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

Successfully merging this pull request may close these issues.

2 participants