feat: stateless fuzzing tests #2144
Conversation
✅ Deploy Preview for kleros-v2-neo ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for kleros-v2-testnet ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
❌ Deploy Preview for kleros-v2-testnet-devtools failed. Why did it fail? →
|
WalkthroughIntroduces a configurable numberOfRulingOptions state in ArbitrableExample with a governance setter, replacing hard-coded values in dispute creation. Adds multiple fuzz tests across appeals, disputes, drawing, execution, staking, and voting to exercise variable ruling options, amounts, iterations, and balances. Minor assertion text tweak. Possible duplicate tests in execution. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor Owner
actor User
participant Arbitrable as ArbitrableExample
participant Core as KlerosCore (Arbitrator)
participant Jurors
Owner->>Arbitrable: changeNumberOfRulingOptions(n)
note right of Arbitrable: Stores n in numberOfRulingOptions
User->>Arbitrable: createDispute(...)
Arbitrable->>Core: createDispute(numberOfRulingOptions)
Core-->>Arbitrable: disputeID
Core->>Jurors: Draw and notify
Jurors->>Core: Cast votes (1..n)
User->>Core: (optional) Fund appeal(s)
Core->>Jurors: Appeal rounds (as needed)
Core-->>Arbitrable: Ruling (1..n)
Arbitrable-->>User: Enforce ruling
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (10)
contracts/test/foundry/KlerosCore_Disputes.t.sol (1)
150-193: Bound fuzzed value instead of assuming; reduces discarded runs and flakiness.Use bound to keep runs in-range deterministically.
Apply this diff:
- // Cap it to 10 eth, so the number of jurors is not astronomical. - vm.assume(disputeValue >= arbitrationCost && disputeValue <= 10 ether); - vm.deal(disputer, 10 ether); + // Cap it to 10 eth, so the number of jurors is not astronomical. + disputeValue = bound(disputeValue, arbitrationCost, 10 ether); + vm.deal(disputer, 10 ether);contracts/test/foundry/KlerosCore_Appeals.t.sol (1)
569-628: Prefer bound over assume for appealValue.Keeps runs within limits and reduces discarded cases.
Apply this diff:
- vm.assume(appealValue <= 10 ether); - vm.deal(crowdfunder1, 10 ether); + appealValue = bound(appealValue, 0, 10 ether); + vm.deal(crowdfunder1, 10 ether);contracts/test/foundry/KlerosCore_Staking.t.sol (4)
10-10: Remove unused console import.Apply this diff:
-import {console} from "forge-std/console.sol";
446-501: Use bound to constrain stake amounts; avoids discarded fuzz runs.Apply this diff:
- vm.assume(firstStake >= minStake && firstStake <= stakerSupply); - vm.assume(secondStake >= minStake && secondStake <= stakerSupply); + firstStake = bound(firstStake, minStake, stakerSupply); + secondStake = bound(secondStake, minStake, stakerSupply);
502-579: Bound stake amounts for the second court scenario as well.Apply this diff:
- vm.assume(firstStake >= minStake && firstStake <= stakerSupply / 2); // Split the supply into two because courts are different now - vm.assume(secondStake >= minStake && secondStake <= stakerSupply / 2); + firstStake = bound(firstStake, minStake, stakerSupply / 2); // Split the supply into two because courts are different now + secondStake = bound(secondStake, minStake, stakerSupply / 2);
580-620: Constrain iterations to realistic bounds to speed up fuzzing.Only up to 4 delayed stakes exist here.
Apply this diff:
- // Test with large numbers but do not trigger possible overflow - vm.assume(iterations < 2 ** 128); + // Keep within a practical bound; there are only 4 delayed stakes in this test. + iterations = bound(iterations, 0, 8);contracts/test/foundry/KlerosCore_Drawing.t.sol (2)
125-164: Bound iterations to avoid pathological values and OOG risk.Apply this diff:
- core.draw(disputeID, iterations); + iterations = bound(iterations, 0, DEFAULT_NB_OF_JURORS * 8); + core.draw(disputeID, iterations);
165-209: Prefer bound over assume; also constrain iterations relative to jurors.Apply this diff:
- // Cap it to 10 eth, so the number of jurors is not astronomical. - vm.assume(disputeValue >= arbitrationCost && disputeValue <= 10 ether); - vm.deal(disputer, 10 ether); + // Cap it to 10 eth, so the number of jurors is not astronomical. + disputeValue = bound(disputeValue, arbitrationCost, 10 ether); + vm.deal(disputer, 10 ether); @@ - core.draw(disputeID, iterations); + iterations = bound(iterations, 0, (disputeValue / feeForJuror) * 8); + core.draw(disputeID, iterations);contracts/test/foundry/KlerosCore_Execution.t.sol (2)
752-789: Constrain iterations to a sane range for execute().Prevents excessive loop requests and speeds up fuzzing.
Apply this diff:
- core.execute(disputeID, roundID, iterations); + iterations = bound(iterations, 0, DEFAULT_NB_OF_JURORS * 16); + core.execute(disputeID, roundID, iterations);
790-850: Bound disputeValue and iterations; keep iterations relative to juror count.Apply this diff:
- // Cap it to 10 eth, so the number of jurors is not astronomical. - vm.assume(disputeValue >= arbitrationCost && disputeValue <= 10 ether); - vm.deal(disputer, 10 ether); + // Cap it to 10 eth, so the number of jurors is not astronomical. + disputeValue = bound(disputeValue, arbitrationCost, 10 ether); + vm.deal(disputer, 10 ether); @@ - core.execute(disputeID, roundID, iterations); + iterations = bound(iterations, 0, nbJurors * 16); + core.execute(disputeID, roundID, iterations);
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
contracts/src/arbitration/arbitrables/ArbitrableExample.sol(2 hunks)contracts/test/foundry/KlerosCore_Appeals.t.sol(1 hunks)contracts/test/foundry/KlerosCore_Disputes.t.sol(2 hunks)contracts/test/foundry/KlerosCore_Drawing.t.sol(1 hunks)contracts/test/foundry/KlerosCore_Execution.t.sol(1 hunks)contracts/test/foundry/KlerosCore_Staking.t.sol(3 hunks)contracts/test/foundry/KlerosCore_Voting.t.sol(2 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (11)
- GitHub Check: Redirect rules - kleros-v2-testnet
- GitHub Check: Redirect rules - kleros-v2-testnet
- GitHub Check: Redirect rules - kleros-v2-neo
- GitHub Check: Header rules - kleros-v2-testnet
- GitHub Check: Header rules - kleros-v2-testnet
- GitHub Check: Header rules - kleros-v2-neo
- GitHub Check: Pages changed - kleros-v2-testnet
- GitHub Check: Pages changed - kleros-v2-testnet
- GitHub Check: Pages changed - kleros-v2-neo
- GitHub Check: Analyze (javascript)
- GitHub Check: hardhat-tests
🔇 Additional comments (3)
contracts/src/arbitration/arbitrables/ArbitrableExample.sol (1)
43-44: Good move: centralize ruling options in storage.This reduces duplication and aligns dispute creation with runtime configuration.
contracts/test/foundry/KlerosCore_Disputes.t.sol (1)
97-97: Assertion message tweak is fine.contracts/test/foundry/KlerosCore_Voting.t.sol (1)
5-5: Import consolidation LGTM.
2 participants
PR-Codex overview
This PR introduces enhancements to the
ArbitrableExamplecontract by adding functionality to manage the number of ruling options in disputes and includes tests for various scenarios related to disputes, voting, and stakes in the Kleros arbitration system.Detailed summary
numberOfRulingOptionsvariable toArbitrableExample.changeNumberOfRulingOptionsfunction to update ruling options.numberOfRulingOptionsdeclarations increateDisputefunctions.Summary by CodeRabbit
New Features
Tests