Unable to use ink tests with custom environment about ink HOT 6 OPEN

After some investigation, it would be difficult to support non-standard generic account types in both unit and e2e testing. This is due to the fact that the testing environment assumes AccountId: From<[u8; 32]> allowing the convert keypairs from subxt into public addresses and so on, it is also used when generating default test accounts (Alice, Bob, Dave, ...) assuming the From<[u8; 32]> implementation.

Making this generic can be done with:

1. Introducing the const generic N for From<[u8; N]> allowing the developer to specify the size of the AccountId manually
2. Completely removing the notion of From<> and introducing the trait DefaultAccounts and other traits allowing the developer to specify default test accounts himself

The second approach is less feasible because the E2E framework heavily relies on sr25519 for signing transactions, and uses default polakdot config.

Making this customisable would probably require a lot of configuration on the developer side, something that we want to avoid.

If you want to test your contracts with non-32-byte AccountId, I suggest you do this on the frontend side using JavaScript.

from ink.

It is a good spot we should make AccountId more generic. The fix in tests should easy. However, the reason why you might not be able to instantiate the contract is because pallet-contracts is configured to use the default AccountId.

If you are using some custom node configuration, can you please provide the link so I can reproduce the issue?

from ink.

The custom node is frontier. So basically that node with pallet-contracts setup (similar to this).
However, you mentioned that pallet-contracts uses AccountId. Do you mean pallet-contracts defaults to AccountId32? From what I just checked, it uses AccountId provided by frame_system pallet

from ink.

Do you mean pallet-contracts defaults to AccountId32

Essentially, yes, substrate-contracts-node using AccountId32 which resolves to [u8; 32].

Off-chain testing environment makes an assumption about this in order to generate a set of default accounts. I need to think about the proper way to make AccountId configurable, coz this breaks some assumptions in our testing frameworks

from ink.

Yeah. Probably AccountId should be configurable but also have a default value if none is specified

from ink.

How you suggest I do that? @SkymanOne

from ink.