Cyfrin Updraft.

Post

Share your knowledge.

Cyfrin Moderator Pst.
Mar 29, 2024
Expert Q&A

Function Call Order During Invariant Testing with Foundry

I am currently studying the Invariant part of a course and have a question regarding the execution order of functions when using invariant testing. Specifically, I am looking at the statefulFuzz_testInvariantBreakHandler function which includes the following code snippet:

function statefulFuzz_testInvariantBreakHandler() public {
 vm.startPrank(owner);
 handlerStatefulFuzzCatches.withdrawToken(mockUSDC);
 handlerStatefulFuzzCatches.withdrawToken(yeildERC20);
 vm.stopPrank();

 assert(mockUSDC.balanceOf(address(handlerStatefulFuzzCatches)) == 0);
 assert(yeildERC20.balanceOf(address(handlerStatefulFuzzCatches)) == 0);
 assert(mockUSDC.balanceOf(owner) == startingAmount);
 assert(yeildERC20.balanceOf(owner) == startingAmount);
}

My question pertains to the order in which handlerStatefulFuzzCatches.withdrawToken(mockUSDC) and handlerStatefulFuzzCatches.withdrawToken(yeildERC20) functions are executed in relation to the fuzzing process:

  1. Are these withdrawToken functions called at the beginning of the test, and then the fuzzer attempts to break the invariants by calling other functions?
  2. Or, are these specific withdrawToken calls supposed to be executed after the fuzzer has run through other functions?

I am seeking clarification on whether the specified withdrawToken operations are meant to set up the state for invariant testing. Thank you for your assistance.

  • Solidity
  • Smart Contract
0
1
Share
Comments
.

Answers

1
Cyfrin Moderator Ans.
Mar 29 2024, 10:42

Yes, you are correct. I overlooked the -vvvvv option in Foundry. The withdrawToken functions are invoked at the commencement of the test, following which the fuzzer endeavors to disrupt the invariants by invoking other specified functions in the handler. The sequence of events is as follows:

  1. The statefulFuzz_testInvariantBreakHandler function is executed, encompassing all its operations.
  2. A random function from the Handler contract is invoked.
  3. The state is maintained.
  4. Repeat step 1 until a disruption occurs.

Essentially, in the initial step, all deposits made by the Handler are withdrawn. This process aims to test the robustness of the system by systematically breaking its functionality.

0
Official Answer
Comments
.

Do you know the answer?

Please log in and share it.

We use cookies to ensure you get the best experience on our website.
More info