-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Bring Truffle to 4.0.4 to be able to properly tests asserts on revert. #111
Merged
Merged
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
1e883ce
Brought Truffle to 4.0.4 to be able to properly use asserts on revert.
simondlr 7dccf82
pin package.json versions
simondlr 9ddcfed
Remove reliance on Babel.
simondlr 6416803
Remove babelrc
simondlr 30b2597
Properly remove Babel.
simondlr b045918
Bumped to Truffle 4.0.5 and removed comment.
simondlr File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,11 @@ | ||
module.exports = { | ||
assertRevert: async (promise) => { | ||
try { | ||
await promise; | ||
assert.fail('Expected revert not received'); | ||
} catch (error) { | ||
const revertFound = error.message.search('revert') >= 0; | ||
assert(revertFound, `Expected "revert", got ${error} instead`); | ||
} | ||
}, | ||
}; |
This file was deleted.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like using assertRevert on things that return promises, but for things that only take callbacks might it be more legible to just do the check explicitly inside the callback itself? What do you think @maurelian ?
I think this code is right, it's just a little hairy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, I think I've done the same thing in a previous version of the test suite, but it feels like wrapping and unwrapping at the same time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not 100% sure how to do this without bungling up the usage of async/await?
Here's how I understand it: if it's a callback and not using async/await, then it will resolve in its own asynchronous thread, and then the following lines (49+) will execute independently of the sendTransaction. Won't this break the linear asyncs?
Doesn't this need to be chained as usual then with .then() style promises (or more traditional callback hell)?
Is that the intent? I'm not 100% sure I grok how to fix this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. I didn't consider that there's another
await
call made after this. I was able to get this work though:And I think one callback is reasonable.
Another option could be to promisify it at the top of the file:
then the test itself looks like any other one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that I think about it, if we use just the callback, then we have to add a
done
to this function I think. Because it doesn't return a promise. https://mochajs.org/#asynchronous-codeBut the second thing you wrote I think would work @maurelian
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I'm okay with merging this as-is though and coming back to this question later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, I had tried that, and got a 'resolution method overspecified' error. The sample I shared was working.