Warn in tests when no events are being emitted#6818
Warn in tests when no events are being emitted#6818shawntabrizi wants to merge 2 commits intomasterfrom
Conversation
|
I think it is a great change because I ran into this issue lately. However, I think printing unconditionally could really slow down exactly the test cases where one deliberately set it to 0. Even though the output is captured on success, printing might be even slower than just emitting the event. I guess we need some "print once" logic here. But that would also miss my the point because tests of the same pallet are executed inside the same process and some static |
| if block_number.is_zero() { return } | ||
| if block_number.is_zero() { | ||
| // Print a message only in tests warning users about this behavior. | ||
| #[cfg(test)] |
There was a problem hiding this comment.
This does not changes anything outside the crate. The test feature is only enabled for a crate when the crate itself is build for testing. This means, any other crate using frame_system will not print anything.
There was a problem hiding this comment.
Hmm, is there some attribute that does what I intend?
In Substrate, we don't emit events on block zero to prevent genesis construction from creating a ton of events.
See #5463
This nuance occasionally comes up as an issue when people are writing runtime tests, since they would need to know to set the block number to greater than zero in order to start emitting events.
If a user does not set the block number, they may wonder why their tests are failing, for example when trying to inspect the last event being emitted.
This PR adds a simple
printlnstatement which is emitted only during tests. Thus, if a test would fail, a user would see this error message, and hopefully understand this behavior and fix it by increasing the block number.