Skip to content

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

Closed
kopy-kat opened this issue Feb 2, 2024 · 5 comments
Closed

feat(cheatcodes): isolate setEnv to a single test case #6999

kopy-kat opened this issue Feb 2, 2024 · 5 comments
Labels
A-cheatcodes Area: cheatcodes T-feature Type: feature

Comments

@kopy-kat
Copy link

kopy-kat commented Feb 2, 2024

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):

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.23;

import { Test } from "forge-std/Test.sol";

contract EnvFoundryTest is Test {
    function testEnv() public {
        vm.setEnv("SIMULATE", "true");
        assertEq(vm.envOr("SIMULATE", false), true);

        vm.setEnv("SIMULATE", "false");
        assertEq(vm.envOr("SIMULATE", false), false);
    }

    function testEnv2() public {
        assertEq(vm.envOr("SIMULATE", false), false);
    }
}
@kopy-kat kopy-kat added the T-feature Type: feature label Feb 2, 2024
@gakonst gakonst added this to Foundry Feb 2, 2024
@github-project-automation github-project-automation bot moved this to Todo in Foundry Feb 2, 2024
@kopy-kat
Copy link
Author

kopy-kat commented Feb 2, 2024

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

@malik672
Copy link
Contributor

malik672 commented Feb 3, 2024

tbh I don't 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

@zerosnacks
Copy link
Member

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 won't fix?

@zerosnacks zerosnacks added the A-cheatcodes Area: cheatcodes label Jul 10, 2024
@zerosnacks zerosnacks changed the title Isolating setEnv to a single test case feat(cheatcodes): isolate setEnv to a single test case Jul 10, 2024
@kopy-kat
Copy link
Author

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.

@zerosnacks
Copy link
Member

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 not planned and close the ticket as there is no immediate actionable point

Again thanks for your suggestion, if you have any ideas / requirements regarding extensions feel free to comment on that ticket

@zerosnacks zerosnacks closed this as not planned Won't fix, can't repro, duplicate, stale Jul 12, 2024
@jenpaff jenpaff moved this from Todo to Completed in Foundry Sep 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-cheatcodes Area: cheatcodes T-feature Type: feature
Projects
Archived in project
Development

No branches or pull requests

3 participants