You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Image setup, where I have an external contract and I want to test, that it's called when a condition is met.
contract Foo {
Set set;
function foo(uint256 x) external {
if (x < 100) {
set.remove(x);
}
}
}
Currently I can easily test the first condition, where x < 100:
function test_removeFromSet_whenLessThen100() external {
uint256 x = 80;
vm.expectCall(
address(set),
abi.encodeWithSignature("remove(uint256)", x);
);
foo(x);
}
But if I want to test the second condition, I have no easy way how to do that:
function test_notRemoveFromSet_whenMoreOrEqThen100() external {
uint256 x = 110;
vm.?????;
foo(x);
}
One workaround is to instantiate the actual Set contract and check for storage changes, but I would rather mock everything in my unit tests.
I would like to propose new assertion cheatcode expectNoCall as a counter party to an exiting one, but this would fail if a call occurs.
New possible test would look like this:
function test_notRemoveFromSet_whenMoreOrEqThen100() external {
uint256 x = 110;
vm.expectNoCall(
address(set),
abi.encodeWithSignature("remove(uint256)", x);
);
foo(x);
}
Optionally it's possible to propose expectNoRevert, expectNoEmit to have consistency around assertion cheatcodes, but I don't think it's necessary at the moment.
The text was updated successfully, but these errors were encountered:
Image setup, where I have an external contract and I want to test, that it's called when a condition is met.
Currently I can easily test the first condition, where
x < 100
:But if I want to test the second condition, I have no easy way how to do that:
One workaround is to instantiate the actual
Set
contract and check for storage changes, but I would rather mock everything in my unit tests.I would like to propose new assertion cheatcode expectNoCall as a counter party to an exiting one, but this would fail if a call occurs.
New possible test would look like this:
Optionally it's possible to propose expectNoRevert, expectNoEmit to have consistency around assertion cheatcodes, but I don't think it's necessary at the moment.
The text was updated successfully, but these errors were encountered: