Check the test migrations effort from the original Foundry project into Polkadot-Foundry

[smiasojed]

Description:
Analyze what it would take to run the existing test suite of a project (currently using standard Foundry/Forge) on top of Polkadot-Foundry. The goal is to evaluate compatibility of Forge tests when executed with the Polkadot-Foundry toolchain.

Please do it the investigation based on the selected tier-1 customer project

Acceptance Criteria:

• 1. Identify project’s current Forge test setup (dependencies, cheatcodes, configs).

• 2. Run tests against Polkadot-Foundry and record compatibility issues.

• 3. Check if project’s cheatcodes, and contract assumptions work under Polkadot-Foundry.

• 4. Categorize tests into:

• Work out of the box,

• Require minor changes (configs, cheatcodes, etc.),

• Blocked due to missing features in Polkadot-Foundry.

• 5. Estimate effort to fully migrate.

• 6. Provide documentation for adapting the project to use Polkadot-Foundry in forge test.

[alexggh]

@Jan-Jan @TorstenStueber: Can you help us with 1 or 2 smart contracts projects that you consider top priority and use forge tests, so that we prioritise those.

[TorstenStueber]

DM'd you.

[alexggh]

Using Morpho, Aave, Balancer to guide this:

Morpho

Forge tests located here, they all pass when run with forge test.

Compiling with --resolc-compile

Out of the box we get an error because of this paritytech/revive#91.

Contract `test/forge/integration/AuthorizationIntegrationTest.sol:AuthorizationIntegrationTest` compiling error: 
The contract `test/forge/integration/AuthorizationIntegrationTest.sol:AuthorizationIntegrationTest` LLVM IR generator definition pass error: Library `test/forge/helpers/SigUtils.sol:SigUtils` not found in the project
The contract `test/forge/integration/AuthorizationIntegrationTest.sol:AuthorizationIntegrationTest` LLVM IR generator definition pass error: Library `test/forge/helpers/SigUtils.sol:SigUtils` not found in the project

Can be fixed with

--- a/test/forge/helpers/SigUtils.sol
+++ b/test/forge/helpers/SigUtils.sol
@@ -8,7 +8,7 @@ import {Authorization} from "../../../src/interfaces/IMorpho.sol";
 library SigUtils {
     /// @dev Computes the hash of the EIP-712 encoded data.
     function getTypedDataHash(bytes32 domainSeparator, Authorization memory authorization)
-        public
+        internal
         pure
         returns (bytes32)
     {

Used cheatcodes:

Number of calls	Cheat name	Status
977	startPrank
473	stopPrank
173	warp	DONE
163	roll	DONE
137	prank
6	sign
2	store

VM assertions

Number of calls	Assertion name
75	expectRevert
27	expectEmit

VM utils:

Number of calls	Function name
1250	label
1005	addr
158	assume
22	toString

Other Mentions

• The tests use various mock contracts, that get injected into the contract under test Morpho, but as far as I can tell the MockContracts don't use any cheat code so I would expect they run alright in pallet-revive.

• Compilation times are huge when compared with solc, a few minutes vs a few seconds, known issue.

• When running with --resolc-startup the tests failed with:

[FAIL: Contract creation failed: Module(
    ModuleError {
        index: 3,
        error: [
            18,
            0,
            0,
            0,
        ],
        message: Some(
            "DuplicateContract",
        ),
    },
)]

Next

Comeback to this contracts tests once:

• Required cheats codes are implemented.
• Support for assertions is implemented.
• Fix reason for --resolc-startup failing with DuplicateContract

[alexggh]

AAVE

For tests located here, they all pass when executing with:

cp .env.example .env
forge test

Compiling with --resolc-compile

Compiler gets killed on my 64 GiB machine, with it eating most of the memory.

Used cheat codes

Number of calls	Cheat name
7297	load
7273	store
5497	startPrank
5417	stopPrank
2371	prank
2391	record
2391	accesses
834	etch
793	ffi
410	warp
369	getBlockTimestamp
162	roll
137	getBlockNumber
103	snapshotGasLastCall
56	deal
33	mockCall
39	sign
29	clearMockedCalls
16	setNonce
2	chainId
3	getNonce

VM assertions

Number of calls	Assertion name
456	expectEmit
356	expectRevert

VM utils

Number of calls	Function name
3776	addr
258	assume
6019	label

Other mentions

The test use mock object that get injected into the contract under test, but at first sight the mocks don't seem to be using cheatcodes, so I think we won't the limitation that cheatcodes are available only at the top level.

Next

• Comeback to it once we figure it out why compiling is eating more than 64GiB.