Open PaulRBerg opened 1 year ago
Is this a duplicate of https://github.com/foundry-rs/foundry/issues/858? It sounds like a more narrow version that issue
This is not quite the same as #858 (table tests).
A table test is an explicit set of input(s) + output(s).
Whereas in this issue, I suggested implementing a new mode of unit testing, a mode specifically meant for unit testing a range of callers. There's no notion of outputs in my proposal.
Component
Forge
Describe the feature you would like
Scenario: a contract function allows the caller to be one of two special accounts:
Testing this sort of function is annoying because I have to duplicate logic in my tests, e.g.
Now, I know I could de-dup the assertions in a subroutine, like this:
But I wouldn't say I like this approach because it (i) hurts the readability of the tests and (ii) doesn't scale super well (e.g. in realistic scenarios, Bob has specific permissions that Alice doesn't have, which requires branching, which in turn complicates the subroutine).
It would be helpful if Forge lent a hand for this use case. I imagine that a new cheatcode could be implemented, e.g.
vm.consider
, which would be similar tovm.assume
and would work something like this:vm.consider
in a test, it runs the test with all provided addresses, one test run for each address. Basically,vm.consider
would run a batch ofchangePrank
under the hood (related: https://github.com/foundry-rs/foundry/issues/4779)setUp
), but it lets the user change the prank during the testWith this hypothetical
vm.consider
, I could write my test like this:Side notes:
vm.consider
is just a suggestion. I don't think it's a great name. Alternatives:vm.regard,
vm.rollPrank
,vm.testPrank
.