Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Content directory smart contracts: Bridge contracts initial tests #1681

Closed
Lezek123 opened this issue Nov 11, 2020 · 0 comments
Closed

Content directory smart contracts: Bridge contracts initial tests #1681

Lezek123 opened this issue Nov 11, 2020 · 0 comments

Comments

@Lezek123
Copy link
Contributor

Lezek123 commented Nov 11, 2020

At the beginning we can use Ganache to run the tests.

This would mean we would use ethereum rpc interface, so we obviously aren't able to test integration with a substrate runtime, but we can do some basic tests to make sure that the main contract logic works as expected

Eventually we will want to have tests that use the substrate api to intract with the contracts and be also able to verify if the intreactions between substrate runtime and evm work as expected. At this point we can decide whether we should maintain two separate sets of tests (unit and integration) and whether unit tests should rely on eth-compatible rpc interface or use the substrate api.

Bridge contracts

For initial tests we will use some predefined key that will act as a "runtime key".

We will also need to preserve some state of bridge contracts in order to be able to succesfully perform other tests (channels, videos, curator groups etc.), as they will rely on bridge contracts state to validate sender permissions.

Initialization

Batch insert

  • success case (verify storage changed as expected)
  • access denied case (wrong key)
  • override case (verify batch insert does not override existing data)

Finish initialization

  • access denied case
  • already finished case
  • success case (verify batchInsert can no longer be used)

Hooks

Memberships - addMemberControllerAddress

  • success case (verify storage changed accordingly)
  • access denied case (wrong key)
  • member address already set case (check if event is emitted)

Memberships - updateMemberControllerAddress

  • success case (verify storage changed accordingly)
  • access denied case (wrong key)
  • member address not set case (check if event is emitted)

ContentWorkingGroup - setLeadAddress

  • success case (verify storage changed accordingly)
  • access denied case (wrong key)
  • address already set case (check if event is emitted)

ContentWorkingGroup - updateLeadAddress, removeLeadAddress

  • success case (verify storage changed accordingly)
  • access denied case (wrong key)
  • lead not set case (check if event is emitted)

ContentWorkingGroup - addCuratorAddress

  • success case (verify storage changed accordingly)
  • access denied case (wrong key)
  • curator address already set case (check if event is emitted)

ContentWorkingGroup - updateCuratorAddress, removeCuratorAddress

  • success case (verify storage changed accordingly)
  • access denied case (wrong key)
  • curator not set case (check if event is emitted)

ContentWorkingGroup - disableLead

  • success case (verify storage changed accordingly)
  • access denied case (wrong key)
  • already disabled case
  • optionally: no lead set case

ContentWorkingGroup - enableLead

  • success case (verify storage changed accordingly)
  • access denied case (wrong key)
  • already enabled case
  • optionally: no lead set case
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants