-
Notifications
You must be signed in to change notification settings - Fork 2k
feat(cheatcodes): isolate setEnv
to a single test case
#6999
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
Comments
tbh I dont have a specific feature request but wanted to find out whether this is still a wont fix or whether there could be a possible feature that helps with this issue |
simple create a separate cheatcode to isolate env to each test case, maybe call setEnvAll and the other setEnv |
Hi @kopy-kat, Since it has been a while since this ticket was opened I'm curious whether you've been able to find a workaround? The requested feature makes sense to me but this seems like an inherent limitation to environment variables being flat and applied globally It is also not practical to introduce an entirely new set of "local" environment variables with cheatcodes: https://github.com/foundry-rs/forge-std/blob/07263d193d621c4b2b0ce8b4d54af58f6957d97d/src/Vm.sol#L246-L402 or modify the existing behavior of environment variables. cc @mattsse per your comment: #2349 (comment) is this still a |
setEnv
to a single test case
I was looking for this feature in the context of building a foundry-based dev kit and using env vars to run tests in certain modes. The workaround is using both env vars and storage vars to also be able to just run any specific test in a certain mode. Tbh the workaround is not that bad its just not very clean. |
I think this is something we can reconsider when thinking about integration points for extensions / plugins for Foundry #8266 For now however I'll mark it as Again thanks for your suggestion, if you have any ideas / requirements regarding extensions feel free to comment on that ticket |
Component
Forge
Describe the feature you would like
Related to #2349 which was closed as won't fix. The main problem is around
setEnv
setting the env variable for the entire test suite currently running. While this makes sense in some cases (eg forks) it doesnt make sense in others. Specifically, here's an example of a problem I'm running into:We have a testing harness that abstracts some testing away from the dev (in this case account abstraction related). As part of this harness, there are some env flags a user can set in order to modify test behavior or print a gas report. However, it is basically not possible to write unit tests for this harness, since if a single test sets the env var then all tests will be executed with that var set.
Additional context
Example (this will revert on some runs):
The text was updated successfully, but these errors were encountered: