Replies: 1 comment 6 replies
-
|
This is sort of how |
Beta Was this translation helpful? Give feedback.
-
|
If you're thinking of pulling state from a live network we do support forking mode, is that the ask? |
Beta Was this translation helpful? Give feedback.
-
|
No, that's not the ask. but having forking capabilities make it even more compelling not sure how to reformulate the ask but let me try :) setUp is not enough when you actually want to deploy to mainnet, for various reasons including :
this means you ll have some script written in some language that allow these features so you can actually deploy your contract on a real network What I ask is the way to link the scripts to the tests themselves. Because after all, without that, most of your What I ask is a way to remove that duplication, so you can write the deployment procedure only once and have these used in test. This is the killer feature of |
Beta Was this translation helpful? Give feedback.
-
|
Ah! Deployment UX is being discussed in #402. Could be cool to have a feature where you could reuse that deployment in |
Beta Was this translation helpful? Give feedback.
-
|
Cool, Don't get me wrong, there is of course many case where Because in that case, you do not want to introduce false positive when you forgot to update your setUp call after changing your deployment procedure elsewhere And with a solution like I describe, you do not even need such setUp function because the system set the test chain to have all that is needed in the first place. |
Beta Was this translation helpful? Give feedback.
-
|
As mentioned in the other issue, you might be able to achieve what you are after by:
Here's how the Here's more: https://onbjerg.github.io/foundry-book/reference/cheatcodes.html#ffi Note that |
Beta Was this translation helpful? Give feedback.
-
Hi, I love the speed of forge and its use of solidity for testing.
One thing I see missing with that though is the ability to test actual deployment setup.
In hardhat world, you can setup your deployment procedure, including the various dependencies among the smart contract as well as the arguments that depends on off-chain computation (merkle root configuration for example) that you will actually execute against a real network.
And more importantly, you do it only once and can then re-use these exact deployment procedures in your tests. (and with forking, you even run such test on the "real" network). This allow you to test the real thing and ensure the params used in your deployment make sense.
This allow your test to focus on the actual behaviour without having to instantiate each smart contract again and duplicating the deployment procedure. (doing that introduce the risk of forgetting to update them).
In hardhat world, this is achieved via js deploy script using hardhat-deploy test fixture that will automatically deploy the contract under test and ensure all deployment dependencies are also executed. It also benefit from snapshotting the deployment (using evm_snapshot) so the next test do not need to redeploy the whole thing and still be deterministic.
How do you imagine this in the foundry world ?
Maybe there could be a way for deploying the contract before running the test and using snapshot to revert to that blockhain state before each test.
Like you basically execute whatever request / tx and then record the blockHash, execute test 1, revert to blockHash, execute test 2, etc....
What do you think?
Beta Was this translation helpful? Give feedback.
All reactions