Consider using RuntimeTester to test runtime

[matklad]

In #4497 and #4812 we added runtime-tester infrastructure – a high-level driver for nearcore which can be used to simulate various block processing scenarios. We successfully used it for fuzzing (#4524) and for providing minimal reproductions for issues (#4771).

As an actionable next step, I suggest trying to use this same infra for some of our tests. The goals would be:

• removing code duplication in tests, which slows down feature-development (feat: introduce structure for storing RuntimeConfigs #4698 (comment), Apply block updates to split shards #4847 (comment))
• using runtime tester in anger, to make sure it's API is comprehensive and remains well-supported as the codebase evolves (note: one possible outcome here is that we discover that runtime tester is ill-suited for this purpose)
• experimenting with and creating a standard way to write most of the test for nearcore.

A good candidate is

nearcore/integration-tests/tests/client/process_blocks.rs

Line 3672 in df508ca

Arc::new(nearcore::NightshadeRuntime::new(

file – it contains 6 instances of nearcore::NightshadeRuntime::new and it feel like they all should be replaceable with Scenario APIs.

[matklad]

cc @posvyatokum (as the author of runtime tester), @Longarithm (as both the creator of and the sufferer from some tests which do nearcore::NightshadeRuntime::new)

[stale]

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months.
It will be closed in 7 days if no further activity occurs.
Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity in the last 2 months.
It will be closed in 7 days if no further activity occurs.
Thank you for your contributions.