Skip to content

Replaced assertJump, assertRevert and expectThrow with shouldFail. #1363

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

Merged
merged 7 commits into from
Oct 9, 2018

Conversation

nventuro
Copy link
Contributor

@nventuro nventuro commented Sep 28, 2018

Closes #1362
Fixes #942

I'm not 100% sold on the shouldFail.reverting syntax, but I like that it feels close to chai. Suggestions are welcome.

@nventuro nventuro added tests Test suite and helpers. breaking change Changes that break backwards compatibility of the public API. labels Sep 28, 2018
@nventuro nventuro added this to the v2.1 milestone Sep 28, 2018
@nventuro nventuro requested a review from frangio September 28, 2018 11:49
Copy link
Contributor

@frangio frangio left a comment

Choose a reason for hiding this comment

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

Yeah I really don't like the name shouldFail. I'm also not sure how I feel about the reverting name only making sense in the context of shouldFail.reverting. But I don't have other suggestions. 😬

return;
}

should.fail(`Expected '${message} failure not received`);
Copy link
Contributor

Choose a reason for hiding this comment

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

There's a missing ' after ${message}.

should.fail(`Expected '${message} failure not received`);
}

function reverting (promise) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Either add async here, or remove it in the next two functions for consistency. I'd add it here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I forgot to remove it from the other two ones. It makes no sense to mark it async unless we await inside it, and since all await in this case is return a promise, I'd rather just do it directly.

Copy link
Contributor

@frangio frangio Oct 3, 2018

Choose a reason for hiding this comment

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

I'd like you to reconsider making the functions async. It makes the return value of the function always be a promise regardless of the type of the return value. It's also like having a type annotation, and likewise it helps when reading the code IMO.

return shouldFailWithMessage(promise, 'invalid opcode');
}

async function outOfGas (promise) {
Copy link
Contributor

Choose a reason for hiding this comment

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

We're not really using this one, so why have it at all? Same for throwing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We'll want to have them once we publish the helpers and remove them from this repo (part of #1204), I'd just leave them be instead of removing them and later bringing them back.

@frangio
Copy link
Contributor

frangio commented Oct 3, 2018

Have you looked into #938? It may have been fixed in #1123 though. Can you check if it's fixed or if we're making the same mistake in the new helper?

@nventuro
Copy link
Contributor Author

nventuro commented Oct 3, 2018

It does look like it was fixed there, but I'd rather not close the issue until we have a test for this helper (which will come after this PR).

come-maiz
come-maiz previously approved these changes Oct 8, 2018
Copy link
Contributor

@come-maiz come-maiz left a comment

Choose a reason for hiding this comment

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

Thank you @nventuro. The tests read nicer now.
I'm not sure if this is the mocha syntax though. Wouldn't be something like this.bounty.cancelBounty.should.fail.reverting ?
I have no idea if that's possible on js, and I don't know where one would put the arguments for cancelBounty.
So this is good to me.

@nventuro
Copy link
Contributor Author

nventuro commented Oct 9, 2018

Yup, the syntax is not the best. I blame should, I'll open an issue sometime soon to see if we want to migrate to expect.

@nventuro nventuro merged commit b0da0fd into OpenZeppelin:master Oct 9, 2018
@nventuro nventuro deleted the less-helpers branch October 9, 2018 19:24
come-maiz pushed a commit that referenced this pull request Oct 21, 2018
…1363)

* Replaced assertJump, assertRevert and expectThrow with shouldFail.

* Fixed linter errors.

* Fixed typo.

* Made the helpers async.

(cherry picked from commit b0da0fd)
@come-maiz come-maiz modified the milestones: v2.1, v2.0 Oct 21, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change Changes that break backwards compatibility of the public API. tests Test suite and helpers.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Remove redundant helpers. unify ethereum revert/throw/etc error expectations
3 participants