-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Conversation
Any particular reason why we include the test-runner here rather than just adding the external repo as a dev-dependency where necessary? |
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. |
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. |
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? |
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. |
We already have tests for all pallets that test their functionality. |
Right, yes we do, but not in a way we can use for testing runtime upgrades? |
Everything that I built in substrate-debug-kit also has the same issue where:
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. |
There was a problem hiding this 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?
bin/node/cli/Cargo.toml
Outdated
@@ -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"] } |
There was a problem hiding this comment.
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.
frame/balances/Cargo.toml
Outdated
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 } |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
aa69638
to
69732ef
Compare
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
thanks for the comment, I just disagree with the first one:
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 Then, we probably don't need to worry about adding one extra function that allows you do do something like
I don't see a companion yet, but ok :D |
@bkchr please take a look at this once more |
Removed my requested change |
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" |
There was a problem hiding this comment.
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
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 🎊