search

district0x / district-registry

A community-curated registry of marketplaces on the district0x Network.
Eclipse Public License 1.0
11 stars 9 forks source link

Smart Contracts Tests #64

Closed madvas closed 5 years ago

madvas commented 5 years ago

Implement smart-contract tests, preferably in truffle, that test all features of smart-contracts.

Differences between MemeFactory TCR and District Registry TCR:

  1. When user creates a district, it has automatically "in-registry" status. There's no challenge period, therefore district can be challenged any time, any number of times. Once a district gets rejected, it can never get back to in-registry state.
  2. Users can stake/unstake DNT into District. Voting token generated from staking DNT is minted according to a curve user chose when creating a district. There are 3 different curves to choose from. Curve type is in code referred to as dntWeight. 3 options are: 1000000, 500000, 333333. image Tests should include testing if number of voting tokens generated correctly follows the curve.
  3. When district is challenged, all DNT that was staked into that district before vote commit period ended, counts as regular votes for keeping in-registry. Vote rewards are also calculated from such votes.
  4. When district is created it also creates related Aragon entity. We don't need to test aragon entity too much in detail, just if somename.aragonid.eth was registered and if it generated aragon dao address. Bonus points, if we can check if aragon apps Voting, Vault, Finance were correctly installed.
  5. Creator of a district can update meta hash of his district, but only if it's in-registry and not currently challenged.

Otherwise, everything else is pretty much same as MemeFactory. ParamChanges should work exactly like MF. So everything related to TCR that's in MF tests, should be here as well, plus tests of features specific for District Registry.

Development:

If you want to deploy contracts for development, you run: 

truffle migrate --network ganache --f 2 --to 3

Migration number 3 just distributes DNT to other accounts from the first one. You may not always need it.

To run tests, you'd run: 

truffle test --network ganache --f 2 --to 3
# or --compile-all to force recompilation of all contracts
truffle test --network ganache --f 2 --to 3 --compile-all

But here's where trouble starts. If I change something in solidity code, just running truffle test ... will ignore changes, even though it recompiles and redeploys all contracts. I found out, if I run those 2 commands one after another, changes are reflected. 

truffle migrate --network ganache --f 2 --to 3
truffle test --network ganache --f 2 --to 3

But this is obviously crazy, because it recompiles and redeploys all contracts twice, every time you want to rerun tests. I think this weird hack is source of further trouble I've hit when trying to write first test in TestDistrictFactory.js. When trying to run transaction that creates district it always reverts. I found out it reverts on those 2 lines: https://github.com/district0x/district-registry/blob/7b2d5aff31e25332da36d3aec4a6644e7711e5ad/contracts/Registry.sol#L154 and https://github.com/district0x/district-registry/blob/028018b2ab2e3593c50c380f0a797a3bb0936a1a/contracts/RegistryEntry.sol#L68 which is very weird, because when I try to run migration 6, which creates a district pretty much the same way as the test, migration works ok. So I have no clue why is this, but I think it is related to a reason why truffle test ignores changes in solidity.