gilescope
commented
2 years ago Sorry I should ask questions sooner rather than waste time trying to figure things out by myself. The substrate-test-runtime is used by the cumulus test environment so I am assuming that we are looking to make the substrate-test-runtime more general and split it into a babe and a aura (and maybe a manual seal one?).
I have been copying across the cumulus as an example, stripping out the relay chain and seeing if I can make that the basis to start from and port the tests to use that rather than using the substrate-test-runtime directly. (and then subsume the bits of substrate-test-runtime that are still needed).
So there will be a substrate/tests dir like cumulus and polkadot and the substrate/test-utils dir will hopefully disappear.
I am not sure if there was a question in there - more a statement of what I am trying to do...
bkchr
The
substrate-test-runtimeis some special kind of runtime that incorporates some FRAME stuff and some custom logic. As the name suggests, it is used for testing. The idea here being to rewrite the test runtime into some "pure" FRAME runtime and to remove other cruft. The runtime contains a lot of stuff for testingsp-apibehavior in wasm vs native. Most of this stuff can probably be removed as we will gonna deprecate the native runtime in the future. This means that we can remove this hugecfg-ifblock. Then the runtime contains the custom extrinsic. These are all the calls this test runtime supports. They are being used all over the code base to test different things. These calls need to rewritten as some FRAME pallet. This means we there should be written one pallet as part of this runtime that exposes the same kind of calls, but through the "FRAME abstraction". All the code that is calling these calls need to be changed to use the FRAMECallenum to achieve the same outcome.The runtime currently also only supports
BABE. There should be two featureswith-babeandwith-aura. Depending on which feature is activated, the respective pallets are activated. As we already enable thedisable-loggingfeature while building the wasm binary, it should be changed in the same way to build with once withBABEand once withAURA.The general idea of this whole issue is that we can continue using the runtime for our unit tests, but we also can write "proper" unit tests for
AURA. In a later future we would also like to have zombienet tests based withAURAso that we can test things like warp syncing etc. Currently we use thekitchensink-runtimefor the zombienet tests. Maybe it would be a good idea to move the "special testing" pallet just to thekithchensink-runtimeand to make this runtime build able withAURA/BABE. Then remove the testing runtime and only use thekitchenshink-runtimefor all tests. However, this may adds more complexity and things that can fail in the unit tests. A simple runtime with just the consensus pallets, the testing pallets and some minimal set of required pallets is probably easier to maintain and to use.