-
Notifications
You must be signed in to change notification settings - Fork 79
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
Mock-builder with generic methods support #1321
Conversation
@NunoAlexandre, @mustermeiszer @branan @wischli @thea-leake @cdamian, not sure who can review this part. Any comment/feedback/question is welcome. 🔓 There is no risk of merging it because all this code is used only for testing. |
8607da3
to
5f13cf4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did no deep deep dive but the changes look sane. But I also think we reached a point with this where moving to procedural macros makes sense in order to have the parsing happen during compilation.
164e8ab
to
acf6440
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some really minor nit-picks from my side. Definitely not blocking, looks good!
/// This function should be called with a locator used as a function identification. | ||
pub fn register<Map, L, F, I, O>(locator: L, f: F) | ||
where | ||
Map: StorageMap<<Blake2_128 as StorageHasher>::Output, CallId>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just as a food for thought: In the future we should probably support other hashers apart from Blake2_128
and handle that with generics. AFAIK, Substrate supports others as well but in most cases blake is preferred.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see right now a use case where a caller would want to choose another Hasher
in this case. I mean, currently, the own crate is who chooses the Hasher, but I need the Map to be generic enough to support different mocks.
But thanks for your thoughts! I keep that in mind in case it evolves in a way a different Hasher
can be useful.
libs/mock-builder/src/storage.rs
Outdated
} | ||
|
||
#[test] | ||
#[should_panic] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe good to check for a more specific panic?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any way to check for a concrete panic? Like the message the panic should return?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I've refactored the code a little bit, to support that case, with better error handling 👍🏻
} | ||
|
||
#[test] | ||
#[should_panic] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above: I would prefer to narrow down the panic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This panic comes from a bad macro usage, and I can not check from the test that "bad usage". Only I can expect it to panic at some point in the macro.
But this panic is ok from a use-case perspective. Tells the user they have configured their mock badly.
5593c63
to
8965594
Compare
Description
This PR gives to
mock-builder
the capability of mocking methods with generic boundsFixes #1316
Changes and Descriptions