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

Feature request: Test event emissions #696

Open
mds1 opened this issue Jul 8, 2021 · 2 comments
Open

Feature request: Test event emissions #696

mds1 opened this issue Jul 8, 2021 · 2 comments

Comments

@mds1
Copy link
Contributor

mds1 commented Jul 8, 2021

It would be great if we could test for certain events and parameter to be emitted. Quoting from the chat on possible syntaxes: https://dapphub.chat/channel/dev?msg=GisKDrLJtiAGzznyE

mds1 12:04 PM
There's a few options I can think of (no idea how implementation of these compares):

  1. First thought was a modifier similar to the revertData modifier discussed above, e.g. expectEvent("MyEvent(uint)", 45) to look for the number 45, or expectEvent("MyEvent(uint)") to consider any uint value passing (or pass the event hash instead of it's signature as a string). One problem with this syntax is you can't specify which call in your test should emit the event
  2. Instead of expectEvent being a modifier, it could just be a method, and when called (with the same syntax as above) it checks the most recent transaction for the event
  3. Last idea is that it could take the target and calldata and execute the call for you, e.g. expectEvent(address target, bytes calldata, string eventSignature, bytes optionalExpectedValues). This would method would need to surface the call's return data so you can still access it if needed

mrchico 3:10 AM
these are good ideas. I think option 2 is my favorite. This could also be done in a cheat code kind of way, perhaps. Like hevm.getLog(index)(bytes), giving the bytestring of the latest-index emitted log

mds1 6:16 AM
Agreed, of those option 2 was my favorite as well. The cheat code approach seems comparable, so no objections there from me. Only question is how would you get the log's bytestring from within your test?

@gakonst
Copy link
Contributor

gakonst commented Sep 4, 2021

+1 it'd be great to have this feature back.

It seems like this was supported in dapple and DSTest but it was removed?

@lucas-manuel
Copy link

Yes I'd love to see this as well.

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

No branches or pull requests

3 participants