Cyfrin Updraft.

Publicación

Comparte tu conocimiento.

Cyfrin Moderator Pst.
Mar 29, 2024
P&R expertos

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
Cuota
Comentarios
.

Respuestas

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
Respuesta Oficial
Comentarios
.

Sabes la respuesta?

Inicie sesión y compártalo.

Cyfrin Updraft is an education platform specializing on teaching the next generation of smart contract developers

200Publicaciones201Respuestas
Sui.X.Peera.

Gana tu parte de 1000 Sui

Gana puntos de reputación y obtén recompensas por ayudar a crecer a la comunidad de Sui.