Integration test for two-hop reserve transfer

[bernardoaraujor]

The XCM workshop slides by @stiiifff present two different reserve-based transfer scenarios:

• 1 hop: xUSD from Statemine to Trappist
• 2 hop: xUSD from Trappist to 3000/Template/Penpal

While working on #51 I only wrote an integration test for the first case. But it's still interesting to have one for the second.

[bernardoaraujor]

parachains-integration-tests is smart enough to figure out the execution sequence of different files in case we give it a directory path.

0_reserve_transfer.yml is already setting the stage in terms of:

• Creating sufficient Asset on Statemine (xUSD)
• Minting xUSD on Statemine
• Creating derivative Asset on Trappist (txUSD)
• Registering xUSD/txUSD on AssetRegistry pallet
• Doing a reserve transfer from Statemine to Trappist (effectively creating a txUSD supply)

therefore, it is not necessary to repeat these steps on a new file.

Ideally, a new file 1_reserve_transfer_two_hops.yml would be written based on the assumption that its execution starts from where 0_reserve_transfer.yml has stopped.

[bernardoaraujor]

encoded call: 0x1f030208000400010300a10f04320504000f0080c6a47e8d03100100010100a10f081300000204320504000b00407a10f35a000e010004010100e12e040d010004000101008eaf04151687736326c9fea17e25fc5287613693c912909cb226aa4794f26a4800e8764817000000

decoded call:

{
  V2: [
    {
      WithdrawAsset: [
        {
          id: {
            Concrete: {
              parents: 1
              interior: {
                X3: [
                  {
                    Parachain: 1,000
                  }
                  {
                    PalletInstance: 50
                  }
                  {
                    GeneralIndex: 1
                  }
                ]
              }
            }
          }
          fun: {
            Fungible: 1,000,000,000,000,000
          }
        }
      ]
    }
    {
      InitiateReserveWithdraw: {
        assets: {
          Wild: All
        }
        reserve: {
          parents: 1
          interior: {
            X1: {
              Parachain: 1,000
            }
          }
        }
        xcm: [
          {
            BuyExecution: {
              fees: {
                id: {
                  Concrete: {
                    parents: 0
                    interior: {
                      X2: [
                        {
                          PalletInstance: 50
                        }
                        {
                          GeneralIndex: 1
                        }
                      ]
                    }
                  }
                }
                fun: {
                  Fungible: 100,000,000,000,000
                }
              }
              weightLimit: Unlimited
            }
          }
          {
            DepositReserveAsset: {
              assets: {
                Wild: All
              }
              maxAssets: 1
              dest: {
                parents: 1
                interior: {
                  X1: {
                    Parachain: 3,000
                  }
                }
              }
              xcm: [
                {
                  DepositAsset: {
                    assets: {
                      Wild: All
                    }
                    maxAssets: 1
                    beneficiary: {
                      parents: 0
                      interior: {
                        X1: {
                          AccountId32: {
                            network: Any
                            id: 0x8eaf04151687736326c9fea17e25fc5287613693c912909cb226aa4794f26a48
                          }
                        }
                      }
                    }
                  }
                }
              ]
            }
          }
        ]
      }
    }
  ]
}

[evilrobot-01]

FYI - working version with both reserve-transfers at https://github.com/paritytech/parachains-integration-tests/blob/frank/trappist/examples/trappist/1_reserve_transfer.yml. Needs finishing with additional checks and refactoring tho.

[evilrobot-01]

Perhaps organisation based on the conventions used at https://github.com/paritytech/parachains-integration-tests/tree/master/examples/collectives-polkadot/0_xcm?

0_init.yml
1_teleport.yml
2_reserve.yml
3_reserve_two_hops.yml

I've got 1 and 3 done based on your 2, so could refactor to create 0 with the hope that maybe one day they can be run via CI.

[bernardoaraujor]

Following my suggestion #76 (comment), it does sound like a good idea!
It would keep some sequential cohesion and also help people coming from the Workshop to understand how integration tests are structured.

However, after some consideration I also realized the following:

We should also keep in mind that ideally on the long term, the integration tests won't necessarily only cover the cases from workshop slides.

As we integrate new features into trappist, we will want to have integration tests for them. And we should also keep some room for a logical separation of integration tests that are somewhat orthogonal to eachother.

Perhaps the two-hop reserve transfer test should follow asset-registry/0_reserve.yml because both are testing the AssetRegistry functionality. But under this same rationale, a test for teleport perhaps should probably fall into a separate directory. As would smart contracts, asset trap, etc.

If we choose to set all tests in sequence now, it might get a bit confusing in the future. Please let me know your thoughts @evilrobot-01 ?

[bernardoaraujor]

Another alternative would be to have a xcm-workshop directory in parallel to different directories dedicated to testing each feature. That way both approaches are covered, although with some redundancy with eachother.

[evilrobot-01]

Agreed, but perhaps a folder per 'use-case' rather than feature, as longer term a particular feature may be involved in multiple use-cases? (i.e. composing various feaures to solve for a use case)

A (rough) suggestion:

integration-tests
  reserve-transfer-asset
    0_reserve_transfer.yml
    1_reserve_transfer_two_hops.yml
  teleport-asset
    0_teleport.yml
  config.toml (currently /xcm-playground.toml)

PS - my additional ideal would be having tests to check for regressions after updates, perhaps via CI longer term.

[stiiifff]

@evilrobot-01 @bernardoaraujor I'm a bit unclear on where we are with this one .. can you share an update ?

[evilrobot-01]

I have #76 which was just building on the work done by Bernardo to get a little more familiar with XCM and Trappist. My PR is dependent on some improvements being merged in https://github.com/paritytech/parachains-integration-tests but I've not had chance to follow up on that since unfortunately.

I have a POC to get implemented over the next few days and then I could get back to it if thats okay?

[evilrobot-01]

I've added #102 and found it much quicker to iterate, test, debug as it effectively removes the need for launching full nodes. It shouldn't replace full integration tests, but can maybe be used as a precursor.

[bernardoaraujor]

I agree that's much better for test-driven-development.

The parachains-integration-tests can be a good way to make a final validation on some solution, but usiging it for development was making things really slow.

Also an insight for #59