Introduces contract demonstrating unit + e2e test event decoding.#1738
Introduces contract demonstrating unit + e2e test event decoding.#1738blairmunroakusa wants to merge 5 commits intouse-ink:masterfrom
Conversation
blairmunroakusa
requested review from
HCastano,
SkymanOne,
ascjones and
cmichi
as code owners
Fixed typos. (e2e -> E2E)
|
@ascjones Hey, I don't understand the reason continuous-integration/gitlab-examples-fmt fails. Do you have the cycles to help with that? |
| @@ -0,0 +1,11 @@ | |||
| # Testing Events Reference Implementation | |||
|
|
|||
| Capturing events for ink! end-to-end tests in particular is not clearly documented, nor are there clear reference implementations. This contract contains a minimalist flipflop contract that emits two different events when called. It contains both unit and e2e test modules illustrating one way to check for multiple events in both testing environments. | |||
There was a problem hiding this comment.
This contract contains a minimalist flipper contract that emits two different events when called. It contains both unit and e2e test modules illustrating one way to check for multiple events in both testing environments.
|
|
||
| type Event = <TestingEventDecode as ::ink::reflect::ContractEventBase>::Type; | ||
|
|
||
| fn decode_events(emitted_events: Vec<EmittedEvent>) -> Vec<Event> { |
There was a problem hiding this comment.
This is actually a very useful function to be added to e2e create directly. Can you please look into this?
There was a problem hiding this comment.
To clarify, do you mean reimplement this decode_events function to work within the ink_e2e test scope? Or do you mean include this particular decode_events function as ink::env::test::decode_events? Or both?
If the former, this would be part of the followup issue regarding improving event decode to not be so awkward.
In any case, this might be something @ganesh1233456 or @alessandro-baldassarre may wish to address individually. I will see to it that the proper issues are created.
There was a problem hiding this comment.
I think for unit tests, we want to have something like ink::env::test::recorded_events().decode() or ink::env::test::decoded_events(). To check whether the events have been emitted, you can use something like .contains() or similar list functions.
With e2e tests it's a little bit trickier, we probably want to have something like let flip_event = flipflop_result.events.find_decoded::<FlipEvent>() or similar to automatically check whether the event has been emitted, decode it and then assert on its values.
|
|
||
| Capturing events for ink! end-to-end tests in particular is not clearly documented, nor are there clear reference implementations. This contract contains a minimalist flipflop contract that emits two different events when called. It contains both unit and e2e test modules illustrating one way to check for multiple events in both testing environments. | ||
|
|
||
| The end-to-end event test/check is awkward and could certainly be improved on. |
There was a problem hiding this comment.
Can you please create a follow-up issue for this?
|
Please run |
|
Converted to draft as more work to be done. |
|
Hi @blairmunroakusa, since you opened this PR we have changed the way we emit events, see #1827. So have a look at the example I added as part of that PR: https://github.com/paritytech/ink/blob/master/integration-tests/events/lib.rs. I'll close this for now, but feel free to reopen it or open a new one which is compatible with Events 2.0 |
|
Hey @ascjones @SkymanOne sorry for ghosting :/ ; life got me. When I find the cycles, I will look into following through on this. Thank you for the cordial and educational intro to the Parity world; I appreciate your patience and professionalism, and I look forward to properly contributing when the time is right. |
3 participants
I did my best to satisfy the contributor guidelines. Please let me know if anything needs revision.