Skip to content
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

Added hevm.sol #21

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Added hevm.sol #21

wants to merge 4 commits into from

Conversation

crisgarner
Copy link

@crisgarner crisgarner commented Aug 21, 2021

This allow to simply import the hevm abstract contract in the test contracts to easily create an Instance a use some of the cheats to improve testing. Usage:

...
import "ds-test/hevm.sol";
...
Hevm hevm;
 
function setUp() public {
    hevm = Hevm(HEVM_ADDRESS);
}
...
function test_X() public {
    hevm.warp(1 weeks);
}

@crisgarner crisgarner changed the title Create hevm.sol Added hevm.sol Aug 21, 2021
@d-xo
Copy link
Contributor

d-xo commented Aug 23, 2021

Thanks! The reason we haven't done this to date is that since ds-test is used in basically every dapptools project, and dapp currently expects that there is a single globally consistent version of every package in the tree, an update to ds-test has historically been rather painful to orchestrate since it generally requires recursively updating a huge amount of submodules. For this reason we decided to keep the Hevm interface out of ds-test since it let us add new cheatcodes without having to go through the hassle of a ds-test update.

However, once dapphub/dapptools#719 lands, this shouldn't be nearly as much of an issue, and I would be happy to add the interface to ds-test.

I do have a few requests however:

  1. Can you please add a storage var hevm to the DSTest contract (e.g. Hevm hevm = Hevm(HEVM_ADDRESS);), this way users of ds-test can just call hevm.<cheat-code> in any contract that inherits from DSTest.
  2. Can you please reformat the Hevm interface declaration in hevm.sol so that each method declaration is on one line, and there are no newlines between method declarations (like this).

@crisgarner
Copy link
Author

Awesome will add them soon.

@crisgarner
Copy link
Author

Thanks! The reason we haven't done this to date is that since ds-test is used in basically every dapptools project, and dapp currently expects that there is a single globally consistent version of every package in the tree, an update to ds-test has historically been rather painful to orchestrate since it generally requires recursively updating a huge amount of submodules. For this reason we decided to keep the Hevm interface out of ds-test since it let us add new cheatcodes without having to go through the hassle of a ds-test update.

However, once dapphub/dapptools#719 lands, this shouldn't be nearly as much of an issue, and I would be happy to add the interface to ds-test.

I do have a few requests however:

  1. Can you please add a storage var hevm to the DSTest contract (e.g. Hevm hevm = Hevm(HEVM_ADDRESS);), this way users of ds-test can just call hevm.<cheat-code> in any contract that inherits from DSTest.
  2. Can you please reformat the Hevm interface declaration in hevm.sol so that each method declaration is on one line, and there are no newlines between method declarations (like this).

Just committed the suggested changes. And tested them in a local repo 😉

src/hevm.sol Outdated Show resolved Hide resolved
@transmissions11
Copy link

transmissions11 commented Aug 24, 2021

@d-xo would having an hevm contract as a public state var for every test mess with the invariant targeting?

Might force everyone to use an targetContracts method

@d-xo
Copy link
Contributor

d-xo commented Aug 25, 2021

Test contracts are excluded by default from invariant tests so I think we should be fine.

@transmissions11
Copy link

Test contracts are excluded by default from invariant tests so I think we should be fine.

But Hevm isn't a test contract?

@transmissions11
Copy link

transmissions11 commented Aug 25, 2021

I mean its not really even a real contract but just want to make sure it being exported as a state var won't cause it to be picked up by the invariant fuzzer.

Does the calling the hevm address with IS_TEST() return true?

@d-xo
Copy link
Contributor

d-xo commented Aug 25, 2021

oh hehe, whoops I was sleepy this morning 🤦‍♀️. We also ignore contracts that have no code so hevm is not included in invariant tests by default.

@PaulRBerg PaulRBerg mentioned this pull request Aug 12, 2022
7 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants