Foundry test execution model and hardhat integrations...

[aathan]

Having read https://book.getfoundry.sh/config/hardhat and other parts of the book, I'm left with some open questions. While I can find the answers by diving into the source code, I thought it's worth asking here. Perhaps summarizing any answers and including them in The Book or elsewhere would be a good idea (if they're not already there!)

(1) When I run forge test -m sometest what EVM context does that test run in? Does foundry itself contain a mock EVM that executes the byte code of the test? Are all of the "cheat codes" essentially working against that "in memory" version of the blockchain state? Does this imply there are always two EVMs ... one used to run the test and the other used by whatever the RPC URL provider is, to maintain the blockchain state external to forge? What provides forge's EVM context? Is it Anvil?

What is the lifetime of any changes made to the blockchain during a test? For example, if a contract is deployed as part of a test, will a dapp interacting with the same node RPC URL see that contract deployment once the test stops (probably not)? If not, what is the recommended way to orchestrate a test that may involve dapp interactions? ... Maybe that's outside the scope of foundry, and the expectation is that such tests would be coded using facilities such as those exposed by tools meant to be used via a more general purpose language than solidity (such as hardhat with tests in js/ts)?

What is the relationship between foundry.toml settings such as eth_rpc_url = "https://example.com/" and forge test command line parameters such as --fork-url? Does using --fork-url change any of the above answers relative to the lifetime of changes made to the blockchain by tests?

(2) It's also not immediately clear what the relationship between the foundry-rs/hardhat and foundry-rs/hardhat-foundry-template may be (if any)? It appears the the former is aimed at being able to invoke foundry tools from npx/hardhat while the latter is about causing the project structures to be compatible enough so that contracts can be compiled/tested independently by either toolchain?

(3) Is it right to say that the artifacts created by forge build are compatible with hardhat at the file level, but that the directory structures are not compatible, so that neither foundry-rs/hardhat nor foundry-rs/hardhat-foundry-template methodologies would result in a scenario where I can build using forge but deploy/test those output artifacts using hardhat?

I'm still digging into this, but any hints are appreciated.

EDIT: Based on the information in https://book.getfoundry.sh/forge/fork-testing#forking-cheatcodes (see first answer) it seems that tests are indeed run in a "local" foundry EVM and the test contract storage is "local". What isn't entirely clear is whether during a test storage changes made by other contracts/accounts are published to the RPC URL provider (e.g. hardhat node) in some way. I'm guessing no. The entire execution context of tests is internal to forge, and if a hardhat RPC URL is used (e.g. via --fork-url) this is effectively only used to read storage state into the forge EVM, so that it can then be used to execute the test bytecode. All of those changes occur to the local EVM's storage and are not visible to hardhat. Then, the scripting/deployment features that were recently added to forge are the only mechanisms that end up affecting blockchain state outside of the forge execution context.

[aathan]

I found this text under "Fork Cheat Codes" ... seems like this information (and related/expanded material) should be discussed in a dedicated section under the "Tests" chapter of the book:

Important to keep in mind that all test functions are isolated, meaning each test function is executed with a copy of the state after setUp and is executed in its own stand-alone EVM.