Post Code Complete test plan for EC-Changes

[toliaqat]

After the code-complete, we need to verify A3P and Testnets, before we can be confident to deploy this on the mainnet. Let's list down verifications that we need to do and in what environments.

A3P: [list down verification steps and any e2e tests we will run for EC-Change verification]

Mainfork/Ollinet: [list down verification steps and any e2e tests we will run for EC-Change verification]

Emerynet: [list down verification steps and any e2e tests we will run for EC-Change verification]

Devnet (if needed): [list down verification steps and any e2e tests we will run for EC-Change verification]

[otoole-brendan]

@frazarshad @rabi-siddique thinking more on this, it's going to be tricky to validate the changes work on Devnet + emerynet since we have our own gov accounts there (and these are different to what the EC members use on mainnet). I guess we can start from a place of have some arbitrary EC members addresses set up before upgrade, then have it replaced with new members during upgrade then verify that the old members can't vote but the new members can (After they accept) - that's presumably how you've been testing so far right?

[otoole-brendan]

@frazarshad and @rabi-siddique we discussed how we'd test this. For the testnet core eval we'll need to configure 4 gov accounts (3 existing and 1 new account we'll need to create).

Since some scripts and tests use Gov1 and Gov2 let's ensure these two Gov accounts continue to be in the new committee for testing. Let's revoke voting rights for Gov3 and then lets add a new account Gov 4 to the committee and ensure it can propose and vote

Gov 1 - Keep (Propose and Vote) Gov 2 - Keep (Propose and Vote) Gov 3 - Revoke Gov 4 - New (Propose and Vote)

[rabi-siddique]

that's presumably how you've been testing so far right?

@otoole-brendan Yes

[rabi-siddique]

A3P: [list down verification steps and any e2e tests we will run for EC-Change verification]

Currently, we have a two-member committee for A3P, which includes the wallets gov1 and gov2. When the core eval for replacing the electorate is passed on A3P, the electorate has only gov1 as a member. gov2 has been removed from the electorate and also from the highPrioritySenders list.

@otoole-brendan @dckc, is this okay? Or should we consider introducing a new incoming member to the electorate?

[rabi-siddique]

Mainfork/Ollinet: [list down verification steps and any e2e tests we will run for EC-Change verification]

Emerynet: [list down verification steps and any e2e tests we will run for EC-Change verification]

Devnet (if needed): [list down verification steps and any e2e tests we will run for EC-Change verification]

In the current testnet setup, the EC members are:

• gov1
• gov2
• gov3

After updating the electorate:

• gov1 and gov2 are invited to join the new committee and charter.
• gov3 is removed from the electorate.
• A new member, gov4, is introduced and becomes part of the electorate.

[rabi-siddique]

For E2E tests, we already have tests in econ-gov, which are catered towards A3P. @otoole-brendan , are there plans to introduce e2e tests specifically for the testnets? Implementation seems feasible, though we'll need to consider differences like how invitation acceptance works across different environments.

For A3P, once the chain is started, it guarantees the presence of committee and charter invitations in the econ-gov UI. For testnets, it seems that accepting invitations is a one-time thing. This difference suggests we might need to revise our testing approach to account for how testnets handle invitations. Maybe we could manually accept the new committee and charter invitations on testnets and design tests to propose changes to contracts using gov3?

[dckc]

This discussion looks like it's about pre-code-complete stuff; i.e.

• 10194

[otoole-brendan]

For E2E tests, we already have tests in econ-gov, which are catered towards A3P. @otoole-brendan , are there plans to introduce e2e tests specifically for the testnets? Implementation seems feasible, though we'll need to consider differences like how invitation acceptance works across different environments.

For A3P, once the chain is started, it guarantees the presence of committee and charter invitations in the econ-gov UI. For testnets, it seems that accepting invitations is a one-time thing. This difference suggests we might need to revise our testing approach to account for how testnets handle invitations. Maybe we could manually accept the new committee and charter invitations on testnets and design tests to propose changes to contracts using gov3?

@rabi-siddique it seems excessive to test EC accounts accepting new committee invitations for E2E tests. I think the most important thing is we want to ensure we're able to test the EC changes broadly on a testnet which is achieved using those 4 gov accounts and changes we're described above.

One thing I'm not sure on is testing on A3P. So we use only 2 Gov accounts for testing on A3P but 3 (soon to be 4) on testnets?