hashgraph / hashgraph/hedera-forking

Investigate whether is possible to reuse unit tests in validation tests

Open
#265 0 comments 0 reactions 0 assignees View on GitHub
test
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.