acceptance test of upgrade #8961
Assignees
Labels
Comments
This was referenced Feb 22, 2024
|
Let's be sure to move tests like |
|
perhaps a relevant subtask: |
This was referenced Apr 18, 2024
mergify bot
added a commit
that referenced
this issue
Apr 22, 2024
refs: #8961 ## Description Start of #8961, so far just moving the core-eval tests out of upgrade-next so they don't have to be copied forward each time ([comment](#8961 (comment))). ### Security Considerations <!-- Does this change introduce new assumptions or dependencies that, if violated, could introduce security vulnerabilities? How does this PR change the boundaries between mutually-suspicious components? What new authorities are introduced by this change, perhaps by new API calls? --> ### Scaling Considerations <!-- Does this change require or encourage significant increase in consumption of CPU cycles, RAM, on-chain storage, message exchanges, or other scarce resources? If so, can that be prevented or mitigated? --> ### Documentation Considerations <!-- Give our docs folks some hints about what needs to be described to downstream users. Backwards compatibility: what happens to existing data or deployments when this code is shipped? Do we need to instruct users to do something to upgrade their saved data? If there is no upgrade path possible, how bad will that be for users? --> ### Testing Considerations <!-- Every PR should of course come with tests of its own functionality. What additional tests are still needed beyond those unit tests? How does this affect CI, other test automation, or the testnet? --> ### Upgrade Considerations <!-- What aspects of this PR are relevant to upgrading live production systems, and how should they be addressed? -->
|
another relevant subtask: I'm pretty sure such a test was built for upgrade-14, but it no longer runs for new releases. |
|
One thing to consider is whether some tests should be able to setup some state before the upgrade so that it can be used by the acceptance layer after the upgrade. That would likely require setting up a "empty core eval" layer before the |
|
This is will be worked on by BytePitch folks(@anilhelvaci and @Jorge-Lopes) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What is the Problem Being Solved?
Our functional tests are all of HEAD. In
/a3p-integrationwe now have robust testing of upgrades but they only cover the expected changes. We need coverage that the whole product still works as expected after the pending upgrade goes on chain.Description of the Design
Have a virtual (empty) proposal that runs after all the others to test functionality that should always work regardless of upgrades performed.
Call it
z:acceptanceso it will always run last.Its tests should verify that these important functions still work:
Tasks
Security Considerations
Scaling Considerations
Test Plan
To be determined with Product
Upgrade Considerations
The text was updated successfully, but these errors were encountered: