Replicate e2e integration test as emulated - #2958
Conversation
|
@NachoPal Command |
gilescope
left a comment
gilescope
left a comment
There was a problem hiding this comment.
Loving it, lot's of good ideas in here.
…also for BridgeHubs) (#2971) * Extracted some commonality for Kusama/Polkadot (which will be reused also for BridgeHubs) * AssetHubRococo should better use AssetHubKusama runtime * add fund_account --------- Co-authored-by: NachoPal <ignacio.palacios.santos@gmail.com>
| type RuntimeEvent = <Polkadot as Chain>::RuntimeEvent; | ||
|
|
||
| // Dispatchable is completely executed and XCM sent | ||
| pub fn xcm_pallet_attempted_complete(expected_weight: Option<Weight>) { |
There was a problem hiding this comment.
@NachoPal
I would not use two levels of modules here,
why not just move this functions to revelant runtime, e.g.:
impl Kusama {
pub fn xcm_pallet_attempted_complete(expected_weight: Option<Weight>) {...
}
impl Polkadot {
pub fn xcm_pallet_attempted_complete(expected_weight: Option<Weight>) {...
}
...
then usage will be much nicer:
// instead of:
events::polkadot::xcm_pallet_attempted_complete
// use just:
Polkadot::xcm_pallet_attempted_complete
later when we split this common per runtime, it will be easier to refactor,
There was a problem hiding this comment.
other thing is that I think those function looks the same,
and they could be write in generic way for trait Chain with some argument to specific Pallet if needed
There was a problem hiding this comment.
Now that we can have chains impl, yes, I can move it to the impls.
About moving to Chain... xcm-emulator will not compile for someone who is using a chain without one of the expected RuntimeEvents variants. I do not think it is a good idea or necessary. It would fail for those chains that use xTokens pallet instead of XcmPallet, for example.
There was a problem hiding this comment.
I didn't want to, but I ended up using macros. It was too much repetition.
There was a problem hiding this comment.
yes, I got it that xcm-emulator is general, but there is also possiblity to create CumulusChain / PolkadotLikeTelayChain in emulated/common and so on
|
bot fmt |
|
@NachoPal https://gitlab.parity.io/parity/mirrors/cumulus/-/jobs/3338725 was started for your command Comment |
|
@NachoPal Command |
|
All comments addressed |
bkontur
left a comment
bkontur
left a comment
There was a problem hiding this comment.
ok, cool, lets go :),
we can still add imrpovements on the way :)
4 participants
Along with integration the tests for
AssetHub, this PR includes improvements inxcm-emulator:assert_expected_events!execute_with()move_ext_inandmove_ext_outmethods added toTextExtto allow sharing externalities states between tests.RelayandParachaintraitsChaintrait.Runtime,RuntimeEvent,RuntimeCall,RuntimeOriginhave been removed fromdecl_test_relay_chains!anddecl_test_parachains!. The rationale behind this is that they are generated byconstruct_runtime!and we can consider it as a standard. To get a reference to them, a newruntimeattribute has been added. This attribute is expecting the path to the runtime crate, and the formerruntimeattribute has been renamed tocore. It expresses the mandatory building blocksxcm-emulatorneeds to work (for this reason we removedBalancesfromcore).Systemhave been removed, and kept/added only those ones that can be bounded by a trait.RELAY_BLOCK_NUMBERthread variable, keeping relay block number accountability as part of the Relay Chain ExternalityTeststruct and its impl that helps with re-usability avoiding repeating yourself.New helper parachains events methods have been added to each integration-tests crate + relay chain events in the common crate.
Finally, other helper methods such as
xcm_paid_execution,xcm_unpaid_executionandforce_create_and_mint_assethave been added too.