Testing disputable contracts
Guide and API description of different mock contracts.
celeste-helperspackage provides a number of mocks which simulate the DisputeManger, AragonCourt and Arbitrator Manifest API's and their functionality on a basic level. This should help when creating tests for Disputable contracts as you can avoid all the overhead necessary to fork xDai or even deploy a full Celeste instance in your test environment.
As the name implies is an ERC20 token that is easy to instantiate for tests.
TestERC20supports all standard ERC20 methods and events along with additional methods defined in
This contract takes no constructor arguments. The deployer address will automatically be assigned as the token owner. Ownership can queried, transferred and revoked based on Openzeppelin's Ownable API.
address _recipient: Recipient of newly minted test tokens
uint256 _amount: Amount of test tokens to be minted
In accordance to the recommendation in the ERC20 spec a
ERC20.Transferevent is transferred with the
fromaddress being the zero address and the
toaddress being the
Method issues new tokens to recipient. Reverts if caller is not the owner. This is to avoid accidental mints within your tests.
The mock for these contracts is a single contract taking up the functionality and the API of both. The mock only simulates the necessary methods so that evidence can be submitted, disputes can be settled and rulings can be set.
The Dispute Lifecycle is mostly absent for disputes created within the mocks. Once created they'll be open, existing indefinitely until the owner sets a ruling.
closing the evidence period
address _feeToken: Address of token to be used as fee for dispute creation.
The constructor does not emit any events
_feeTokenaddress in an immutable property and sets the instantiating address as the owner of this instance. Uses OpenZeppelin's Ownable API for ownership.
Virtually identical to a
arbitrator.closeEvidencePeriodcall. Exactly the same revert messages are issued if the caller is not the subject or if the dispute does not exist. Also emits the
EvidencePeriodClosedevent. Only difference is it has no effect in terms of shortening the evidence phase.
retrieving a ruling
setting a ruling
uint256 _disputeId: The dispute ID for which the ruling is to be set
uint256 _ruling: Ruling ID (2 / 3 / 4)
Does not emit any events.
- The dispute does not exist yet
- OR The caller is not the owner
_rulingit not 2 / 3 / 4
Directly sets the ruling for a dispute. This is extremely in testing as you can directly simulate a ruling for your disputable contract without having to simulate a full jury selection, vote, appeal etc.
For the arbitrator mock the fee recipient will always be itself.
Since the arbitrator mock is a 2-in-1 AragonCourt and DisputeManger it will return its own address.
Identical to the normal Arbitrator Manifest except it's only compatible with the AragonCourt / DisputeManager mock. The outward facing API is also identical.
For a concrete example on how a test for a Disputable contract using the mocks looks like check out the test for the
WorkAgreementcontract described in the Getting Started section. The test can be found here.