Add E2E testing framework MVP

[cmichi]

MVP for #1234.

I've created a fresh PR to make it easier for reviews.

Contains only E2E tests for our contract-transfer example so far, no cross-contract tests yet. Once we've nailed down the API I'll add E2E tests for the other examples in follow-up PRs. The best way to look at this PR is, I think, to look at the #[ink::e2e_test] tests for the contract-transfer example.

I've annotated a couple of TODO(#xxx) comments ‒ I'll create the issues + add the number before merging, I'm just waiting for approvals beforehand.

[cmichi]

CI currently fails because use-ink/cargo-contract#728 is not yet merged.

[athei]

You can't really collect the output of a contract call with this, right? Because you only dry-run for gas_limit but do not allow to explicitly dry-run for calling non mutable massages.

[SkymanOne]

These are my thoughts. I understand that we don't want to loosely couple cargo-contract and ink, but I personally see some code duplication as an issue because we'll have to change the code in 2 different places if specs are changed.

[cmichi]

You can't really collect the output of a contract call with this, right? Because you only dry-run for gas_limit but do not allow to explicitly dry-run for calling non mutable massages.

@athei Can't fully follow you here, can you elaborate?

[athei]

You can't really collect the output of a contract call with this, right? Because you only dry-run for gas_limit but do not allow to explicitly dry-run for calling non mutable massages.

@athei Can't fully follow you here, can you elaborate?

It looks to me that you are not returning the result (as in the output buffer) to the user of the testing framework.

[cmichi]

You can't really collect the output of a contract call with this, right? Because you only dry-run for gas_limit but do not allow to explicitly dry-run for calling non mutable massages.

@athei Can't fully follow you here, can you elaborate?

It looks to me that you are not returning the result (as in the output buffer) to the user of the testing framework.

The return value of invoking call() on the E2E testing framework is a Result with an Ok of:

/// Result of a contract call.
pub struct CallResult<C: subxt::Config, E: Environment> {
    /// The result of the dry run, contains debug messages
    /// if there were any.
    pub dry_run: ContractExecResult<E::Balance>,
    /// Events that happened with the contract instantiation.
    pub events: TxEvents<C>,
}

The dry_run here is all that the state_call RPC for ContractsApi_call returns. This is how CallResult.dry_run looks:

ContractResult {
        gas_consumed: 5501174466,
        gas_required: 74999922688,
        storage_deposit: StorageDeposit::Charge(0),
        debug_message: [],
        result: Ok(
                ExecReturnValue {
                        flags: (empty),
                        data: Bytes([0, 57, 5, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0])
                }
        )
}

So all of this is returned to the user as part of executing .call(). This should cover anything, right?

[athei]

So all of this is returned to the user as part of executing .call(). This should cover anything, right?

yes

[ascjones]

I think all of these new e2e dependencies should be optional = true, since the e2e code is conditional for std.

Arguably we may even want an additional feature to prevent them being compiled for the metadata generation which is std, there are some hefty dependencies here.