cheatcode for hardhat evm_mine?

[aathan]

Per hardhat docs:

If neither mining mode is enabled, no new blocks will be mined, but you can manually mine new blocks using the evm_mine RPC method. This will generate a new block that will include as many pending transactions as possible.

However, I do not see a corresponding cheatcode in foundry. Any hints?

[cruzdanilo]

vm.roll(block.number + 1);

[aathan]

btw, what that implies is not being able to test (in foundry/solidity code only) contracts that depend on accessing prior block hashes (256 of which are accessible in the EVM) -- although it's not clear to me exactly how a test written in solidity would be "split" across blocks. I haven't fully grok'ed the execution model in hardhat/founry -- as in who's executing the bytecode exactly (foundry or hardhat) and what insertions could be made.

[onbjerg]

You can access the last 256 hashes just fine - I'm not entirely sure what you want from evm_mine that you do not have in the other cheatcodes like roll, warp and so on?

[aathan]

I'm not claiming to know for sure that what I'm discussing is a valid usecase. I'm just noting what could be a hole in what can be tested in Foundry. The issue is not the past 256 hashes, but acting on some sequence of actions that have generated multiple Solidity Events in the context of a system that enforces transactions be in different blocks etc. Seems to me you'd then (to really test it) need to mine blocks, so you've got different block hashes on the various events, and can then properly access the block hashes that got generated during your test in the last test step if say, your system, is verifying signatures sent to it (said block hashes which are now easily accessible in the evm because they are "past"). The point being they'd not be generated by a roll.

This is why I mentioned orchestrating test steps with external functions that are monitoring the chain on which those test steps occur.

Anyway, it's just a theoretical concern at this point. I'm not actually running such tests.

[onbjerg]

Apologies, I'm still not entirely following. When you say external system, do you mean one that listens to the blockchain, like an event watcher? In that case, I'd argue that you should mock this behavior in the event watcher service, and run E2E tests later in a script, which is 100% doable right now. For example, the script could:

1. Spin up a node
2. Deploy the contracts
3. Start the service
4. Call some functions with cast and perform assertions on the service

For smart contracts that require that some action is taken in different transactions, roll and similar cheatcodes are sufficient

[aathan]

Yes ok, I don't want to belabor the conversation -- we're saying the same thing. Your position is that if you want to test things that involve block header based signatures for blocks generated from transactions/activities of the thing you're building/testing ... then orchestrate those tests external to the forge DSTest suite you're writing.