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

Have only one variant of expectEvent #1220

Closed
frangio opened this issue Aug 17, 2018 · 4 comments
Closed

Have only one variant of expectEvent #1220

frangio opened this issue Aug 17, 2018 · 4 comments
Labels
breaking change Changes that break backwards compatibility of the public API. tests Test suite and helpers.

Comments

@frangio
Copy link
Contributor

frangio commented Aug 17, 2018

Our expectEvent helper currently comes in two variants: expectEvent.inLogs and expectEvent.inTransaction. As far as I can tell, we only need one of the two. inTransaction was suggested by @nventuro as the one to keep.

I'd also reconsider whether it should be an async function. It seems like it would make sense as a sync function. We can expect a receipt as the argument and we wouldn't need to await it.

@frangio frangio added kind:improvement tests Test suite and helpers. breaking change Changes that break backwards compatibility of the public API. labels Aug 17, 2018
@frangio frangio added this to the v2.1 milestone Aug 17, 2018
@nventuro
Copy link
Contributor

I don't see a point in making it async, since you'll need to await on your test anyway.

@Aniket-Engg
Copy link
Contributor

inLogs should be removed only from module.exports and used internally for inTransaction or it should be removed completely and functionality of inLogs should be added in inTransaction?

@nventuro
Copy link
Contributor

@Aniket-Engg that's an implementation detail of the helper, use your best judgment :) I think we could safely put it inside inTransaction though.

@nventuro
Copy link
Contributor

Closed via #1511

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

No branches or pull requests

3 participants