hashgraph / hashgraph/hedera-forking
Investigate whether is possible to reuse unit tests in validation tests
- Dominant language
- Solidity
- Stars
- 3
- Forks
- 4
- PR merge metrics
- No merged PRs in 30d
Description
We currently maintain a different test suite to validate real HTS behavior, `test/hts.e2e.js`. This approach, however, is cumbersome, because we needed to manually create tests that runs both emulated and in a real network. Moreover, this introduces a lot of duplication, given we need to repeat our Foundry test suite for validation tests.
Another approach could be to reuse the unit tests we already have. These tests are written in Solidity and executed by Foundry. The main issue is how to run these tests in a remote network. Foundry provides the ability to do so with scripts https://book.getfoundry.sh/guides/scripting-with-solidity and `broadcast/startBroadcast`. For example, the following snippet when run in a script, will be first executed locally (emulated) and then remotely in a real Hedera network.
```solidity
vm.startBroadcast();
IHederaTokenService.HederaToken memory token;
vm.expectRevert(bytes("HTS: must send HBARs"));
IHederaTokenService(HTS_ADDRESS).createFungibleToken(token, 10000, 4);
vm.stopBroadcast();
```
In the example, we can see the behavior is different when run in a remote network. Instead of reverting, it succeeds but returning `INSUFFICIENT_TX_FEE` https://hashscan.io/testnet/transaction/1741378253.499016000.
We can leverage Foundry's execution model to run the same tests both locally and remotely. The main drawback is Solidity's lack of introspection to manipulate test calls. However, we might solve this by dynamically generating scripts to be run remotely.
Contributor guide
Assessment
This issue has not been assessed yet.