-
Notifications
You must be signed in to change notification settings - Fork 27
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 the reward functionality of the native-manager #646
Conversation
9f7de88
to
4ed2f6d
Compare
vm.mockCall({ | ||
callee: account, | ||
msgValue: amount, | ||
data: "", // implies receive() | ||
returnData: "" | ||
}); |
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 wasn't doing anything
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'm not hard opposed to this and agree with your assessment that the current implementation has problems, but not sure that I love divergence (albeit tiny) from the actual contract we want to test and the contract we are actually testing. _reward
is simple enough though that this is probably fine here.
} | ||
|
||
function _setUp() internal override returns (IValidatorManager) { | ||
// Construct the object under test | ||
app = new NativeTokenStakingManager(ICMInitializable.Allowed); | ||
app = new MockNativeTokenStakingManager(ICMInitializable.Allowed); |
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'm not sure that MockNativeTokenStakingManager
is the best name here since you aren't really mocking here but monkeypatching instead. How about TestableNativeTokenStakingManager
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.
done
4ed2f6d
to
d2aa93d
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.
LGTM -- if others think that we don't want this divergence we could theoretically abstract it away behind an interface but I think this is fine for now and improvement over status quo.
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 like this solution. Thanks @richardpringle :)
Why this should be merged
We were actually triggering logic in a function named
_expect*
. It was super misleading and really hard to track down why that was happening. Instead, I've properly mocked the functionality, triggering thevm.deal
logic when the_reward
function is called instead of afterwards.How this works
I've effectively monkey-patched the
_rewardFunction
.How this was tested
It is a test 😉
How is this docuomented
There's a code comment that was already there that I moved.