Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

test runner #7665

Merged
merged 40 commits into from
Mar 24, 2021
Merged

test runner #7665

merged 40 commits into from
Mar 24, 2021

Conversation

seunlanlege
Copy link
Contributor

@seunlanlege seunlanlege commented Dec 3, 2020

Substrate test runner is a new testing kit built specifically for testing runtime upgrades and migrations, It can be used with an existing chain data, to assert that a new runtime upgrade should behave as expected before it even goes live on-chain.

The goal of this project is to have an e2e testing suite that is run on CI whenever runtime code changes, allowing us to test runtime upgrades/migrations in a stress-free manner, previous attempts at this

In order to achieve this goal, pallets need to migrate to using tests written specifically for the test runner, eg see pallet-balances-e2e

These tests are generic and so they can be used to test runtime upgrades/migrations for any runtime 🎊

@seunlanlege seunlanlege added the A0-please_review Pull request needs code review. label Dec 3, 2020
@seunlanlege seunlanlege requested a review from gnunicorn December 3, 2020 13:06
@gnunicorn
Copy link
Contributor

Any particular reason why we include the test-runner here rather than just adding the external repo as a dev-dependency where necessary?

@seunlanlege
Copy link
Contributor Author

seunlanlege commented Dec 3, 2020

Well the test runner depends on substrate master. If we add as an external dependency, there'd be two different versions of substrate in use.

@bkchr
Copy link
Member

bkchr commented Dec 3, 2020

For what do we need this test runner in substrate?

@seunlanlege
Copy link
Contributor Author

For what do we need this test runner in substrate?

This project was originally started with the idea of testing runtime upgrades but in order to get there, we first need a test suite for all pallets. We'd like for these tests to be run in CI as another build step for PR's that touches runtime code and so it doesn't make sense for the tests/runner to live elsewhere.

@bkchr
Copy link
Member

bkchr commented Dec 3, 2020

Please be more specific.

What will these pallet tests do, how will this pallet tests be used later for doing runtime upgrade tests?

How should that work when these tests are written for the Substrate runtime and you want to test a polkadot runtime upgrade?

@seunlanlege
Copy link
Contributor Author

seunlanlege commented Dec 3, 2020

Pallet tests should cover general use case of pallets.

Runtime upgrades can be done on a testnet that tracks substrate releases.

Post upgrades, we can run the test suite using the test runner and assert that no pallet functionality is broken.

For polkadot runtime upgrades, polkadot specific pallets would also need their own tests which will live in the polkadot repo.

@bkchr
Copy link
Member

bkchr commented Dec 3, 2020

We already have tests for all pallets that test their functionality.

@seunlanlege
Copy link
Contributor Author

Right, yes we do, but not in a way we can use for testing runtime upgrades?

@kianenigma
Copy link
Contributor

Everything that I built in substrate-debug-kit also has the same issue where:

  1. Ideally I want it to live inside of substrate because I want it to depend on substrate master.
  2. Ideally (from another perspective) is should live outside of substrate because it is external tooling.

Initially my stance was to go through bit of hassle, but keep this stuff outside of substrate, as I have done before.

I am ambivalent here and will review this next week again.

Copy link
Contributor

@gnunicorn gnunicorn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still unclear of whether this should live here, nor whether this does demonstrate more utility compared to the tests we already have. Is there any way to provide an node-upgrade-case?

@@ -81,7 +81,7 @@ pallet-indices = { version = "2.0.0", path = "../../../frame/indices" }
pallet-timestamp = { version = "2.0.0", default-features = false, path = "../../../frame/timestamp" }
pallet-contracts = { version = "2.0.0", path = "../../../frame/contracts" }
frame-system = { version = "2.0.0", path = "../../../frame/system" }
pallet-balances = { version = "2.0.0", path = "../../../frame/balances" }
pallet-balances = { version = "2.0.0", path = "../../../frame/balances", features = ["tests"] }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think these tests should live here, they are not related to the node-cli and don't test its behaviour. No harm putting them into a new bin/node/e2e-tests-crate, that isn't being published. Would keep things nice and tidy.

Comment on lines 23 to 25
pallet-sudo = { version = "2.0.0", path = "../../frame/sudo", optional = true }
sp-keyring = { version = "2.0.0", path = "../../primitives/keyring", optional = true }
substrate-test-runner = { version = "0.8.0", path = "../../test-utils/substrate-test-runner", optional = true }
num-traits = { version = "0.2.14", optional = true }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here, Why not put them into a sup-crate frame/balances/e2e-tests (non-publish until we've solved the binding issues)? They don't need (and should not need) access to internal types, thus they should be fine depending on the crate but don't have to live in it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

one more reason to get rid of frame/balances/e2e-tests.

Putting the same example in node/bin/testing or sth like that would make much more sense.

generic tests

initial impl

initial impl

merged with master
Seun Lanlege and others added 2 commits March 10, 2021 11:47
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
@kianenigma
Copy link
Contributor

kianenigma commented Mar 10, 2021

thanks for the comment, I just disagree with the first one:

I worry about bloating the boilerplate set up for the test runner, runtime, txpool logs are imo sensible defaults

it is already bloated, because we are configuring much more unrelated stuff like networking and telemetry there in the configs, and I think the underlying issue is this, not the request to add configurable log target.

To me, the correct course of action is to simplify the current one: Specially building Configuration. We probably don't need to allow the full one to be set by user. Could have a TestRunnerConfig that has only a subset of Configuration, and have a From<TestRunnerConfig> for Configuration do the job for you under the hood.

Then, we probably don't need to worry about adding one extra function that allows you do do something like pub fn set_log(&mut self, target: &str, level: log::Level.

6, 7, 8 have also been addressed

I don't see a companion yet, but ok :D

bkchr
bkchr previously requested changes Mar 19, 2021
bin/node/test-runner-example/src/lib.rs Outdated Show resolved Hide resolved
Seun Lanlege and others added 2 commits March 19, 2021 19:03
@shawntabrizi shawntabrizi requested a review from bkchr March 21, 2021 02:59
@seunlanlege seunlanlege added the D3-trivial 🧸 PR contains trivial changes in a runtime directory that do not require an audit label Mar 22, 2021
@seunlanlege
Copy link
Contributor Author

@bkchr please take a look at this once more

@bkchr
Copy link
Member

bkchr commented Mar 24, 2021

Removed my requested change

@seunlanlege seunlanlege merged commit 189d079 into master Mar 24, 2021
@seunlanlege seunlanlege deleted the substrate-test-runner branch March 24, 2021 10:28
Comment on lines +46 to +53
parity-scale-codec = "1.3.1"
env_logger = "0.7.1"
log = "0.4.8"
futures01 = { package = "futures", version = "0.1.29" }
futures = { package = "futures", version = "0.3", features = ["compat"] }
rand = "0.7"
tokio = { version = "0.2", features = ["full"] }
libp2p = "0.35.1"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some of these are unused

hirschenberger pushed a commit to hirschenberger/substrate that referenced this pull request Apr 14, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A0-please_review Pull request needs code review. B0-silent Changes should not be mentioned in any release notes C1-low PR touches the given topic and has a low impact on builders. D3-trivial 🧸 PR contains trivial changes in a runtime directory that do not require an audit
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants