Testing disputable contracts
Guide and API description of different mock contracts.
The
celeste-helpers
package 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.
TestERC20
supports all standard ERC20 methods and events along with additional methods defined in@openzeppelin/contracts/token/ERC20/ERC20.sol
.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 tokensuint256 _amount
: Amount of test tokens to be minted
In accordance to the recommendation in the ERC20 spec a
ERC20.Transfer
event is transferred with the from
address being the zero address and the to
address being the _recipient
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.
instantiating
dispute creation
submitting evidence
closing the evidence period
address _feeToken
: Address of token to be used as fee for dispute creation.
The constructor does not emit any events
Stores the
_feeToken
address 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.closeEvidencePeriod
call. Exactly the same revert messages are issued if the caller is not the subject or if the dispute does not exist. Also emits the EvidencePeriodClosed
event. Only difference is it has no effect in terms of shortening the evidence phase.retrieving a ruling
setting a ruling
getters
uint256 _disputeId
: The dispute ID for which the ruling is to be setuint256 _ruling
: Ruling ID (2 / 3 / 4)
Does not emit any events.
General function
Reverts if:
- The dispute does not exist yet
- OR The caller is not the owner
- OR
_ruling
it 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
WorkAgreement
contract described in the Getting Started section. The test can be found here.Last modified 1yr ago