feat: add basic integration tests #2
Conversation
| * @returns A fresh instance of an [[ObjectBuilder]]. | ||
| */ | ||
| export function dipSiblingProofBuilder(): ObjectBuilder { | ||
| return ObjectBuilder.new<DipSiblingProofInput>() |
There was a problem hiding this comment.
is the object builder not helping?
There was a problem hiding this comment.
I was having some weird TS issues, since the class is exported by the IWith interface on which the class is based is not, and even when I tried to use it in the e2e tests, it was more of a hussle to define a base config and then extend it based on each test case, since all it does is TS magic. I decided to opt out of it, and instead use the config strategy you see in the e2e tests, which is much more ergonomic.
|
|
||
| const okProof = proof.unwrap() as any | ||
| // TODO: Better way to cast this? | ||
| const okProof = proof.asOk.toJSON() as any |
There was a problem hiding this comment.
| const okProof = proof.asOk.toJSON() as any | |
| const okProof = proof.asOk.toJSON() as DipIdentityProofRes |
?
There was a problem hiding this comment.
Conversion of type 'string | number | boolean | AnyJson[] | { [index: string]: AnyJson; } | null | undefined' to type 'DipIdentityProofRes' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.
Type '{ [index: string]: AnyJson; }' is missing the following properties from type 'DipIdentityProofRes': proof, root ts(2352)
There was a problem hiding this comment.
toJSON() returns AnyJSON, which is not compatible with anything, basically.
tests/utils.ts
Outdated
| RegistryTypes, | ||
| } from "@polkadot/types/types" | ||
|
|
||
| const dipProviderCalls: DefinitionsCall = { |
There was a problem hiding this comment.
Is this not something the dip-sdk should just expose? Don't you need that to create an api that connects to a provider chain?
There was a problem hiding this comment.
Good point. While the types are provider-specific, and here they refer to the provider template runtime, the runtime definitions can be exported, so I did just that. What do you think? afc7624
There was a problem hiding this comment.
Yeah makes sense to me. Are there any types on the provider side which are fixed simply because the proof would not verify if you changed them? If so, they could be exposed here as well I guess?
There was a problem hiding this comment.
Mhh the whole identity proof is generic over pretty much everything, so there's nothing more that could be assumed to be part of the provider runtime. The only thing that is fixed is the IdentityCommitmentVersion: "u16" type. Should I export just that? Even the block number and account ID are generic, and I've hit that very same issue myself since Peregrine uses a u64 for the block number and the provider runtime a u32. This whole thing will anyway become outdated once metadata v15 is out.
Partially fixes https://github.com/KILTprotocol/ticket/issues/2975.
Basic integration tests setup based on Zombienet and Kubernetes provider. Currently there is no easy way (or at least I have not found any) to run integration tests in the CI in a predictable way to have access to the ports forwarded for the nodes. Probably there is a way around that, but for now I'd merge this PR (which has helped finding out a bunch of errors in the code) and move on. I also removed the parent stuff as that is less easy to test (requires a custom Polkadot image with the consumer pallet), and while I have verified elsewhere that it works, I will focus on this also later on. What brings the most value is the sibling bridging, which this PR enables.