[E2E alternative backend]: Backend traits

[pmikolajczyk41]

The PR introduces abstraction for all available operations within e2e tests. These actions are broken into two categories:

• general chain utilities (creating endowed account, checking account's balance, etc.)
• contract specific operations (code upload, instantiation, calling)

Thus there are two corresponding separate traits: ChainBackend and ContractsBackend that are combined further into E2EBackend.

Notes / dilemmas

Mutability in backend methods

While so far, the subxt-based E2E client could work just on &self, we have to make all backend methods to operate on &mut self. This is because drink! client will have to keep the whole runtime (externalities) by itself and thus any action will mutate its state.

While some workaround might have been done (with some RefCells etc), IMHO it's completely not worth the effort and complication (at least at this stage).

Asynchronicity of backend traits

While drink backend is inherently synchronous, subxt-based one cannot be. Unfortunately I don't know any ethic way of keeping common facade for such two alternatives and thus I made all methods asynchronous. As a result:

• drink! implementation will be artificially asynchronous, but actually the logic will be instant anyway (there will be no breakpoints in the async state machine)
• the testcase body stays the same, no matter which backend it uses (this is actually one of the goals)

Breaking E2EBackend into two traits

This is just a matter of taste - for me it is just cleaner to separate general-chain logic from the contract-specific (this is how I did it in drink! as well). However, there are 3 immediate downsides:

• e2e test module must import two traits
• there's some redundancy between these traits: they share some associated types, which must be declared twice
• all the trait bounds must be repeated 3 times

I'm not very dedicated to that support, so if any of the reviewers is in favor of having a single trait, I'm on it.

Awful associated types bounds repetition

Since there are actually 3 impl *Backend for Client, there are 3 long blocks of identical lists of trait bounds for the types within E and C (environment and subxt config). Unfortunately, due to: rust-lang/rust#20671 I cannot do much here (unless we want to include unstable feature of trait_alias).

Actor vs ActorId

In the full context (subxt-based client) we usually have to differentiate between user's account and user's keypair: we use the first one to send tokens there or read its state, and the second one for signing transactions, that are sent to a node. However, in drink! backend, there is no need for signing anything, and thus these two concepts can be collapsed to just a user's account.

Dry-running

I am not sure if dry-running should be a part of the backend trait. It seems useful, but it's not that obvious how it should be implemented for drink!... For now I included it and I will see soon what is possible to do about it in drink!.

[pmikolajczyk41]

@ascjones this is now a half-baked PR, but I wanted kindly ask you if you could take a quick look and tell whether the direction is okay with you; if so, then I will continue with ContractsBackend along the same line

[SkymanOne]

LMK when it is ready for review, I will convert the PR to ready

[ascjones]

Looks good so far, carry on!

Not sure about the name Actor, would be interested to know what the equivalent concrete types are for the Drink! backend. That is a minor detail though.

[pmikolajczyk41]

okay, I'm done for the first iteration now - @SkymanOne @ascjones please take a look :) notice that the PR description has been significantly expanded, hopefully giving some help/insights into some of the decisions that I made on spot

[ascjones]

In general this all LGTM.

Another possibility for the interface would be to make it synchronous and adapt the subxt client into sync methods. Though that will require lots of changes to existing tests so let's keep it async for now.

Also if Actor is referring to Account, couldn't we just make the types Account and AccountId?

Anyway, nothing from my side to prevent this PR from being merged. Looking forward to the next one!

[pmikolajczyk41]

I have just merged master and added licenses to the files that I recently created.

Regarding Actor vs Account... it's just my hard discomfort when it comes to semantics :P in the subxt case, type Account = Keypair would look confusing imho; however, if this Actor stings the eyes, I can change it :)

[SkymanOne]

I am personally not a fun of renaming the file into subxt_client.rs. IMO, it is better either to keep the name client.rs or rename it to the impls.rs like it's done in other ink! crates. Since, all the create provides an implementation for the backend traits

[pmikolajczyk41]

I was intending to put drink backend into a separate module (like drink_client.rs) to keep clear isolation of the very different code and hence this renaming. Would you suggest putting everything into a signle client.rs/impls.rs module?

[SkymanOne]

If you plan to integrate drink backend in the ink! e2e crate directly, then it makes sense to keep subxt_client.rs name

[pmikolajczyk41]

that's the plan, so that a developer when writing tests can only specify which backend they need without worrying about dependencies or imports

[SkymanOne]

Then it makes sense to keep the name

[SkymanOne]

Looks way better now. Happy to get it merged!