Willow parameters for testing?

[sgwilym]

From here on out, testing our modules will require an increasing number of Willow parameters to be configured.

In willow-js, I made a kind of test scheme with extremely simplified parameters: NamespaceId was an enum of Project, Work, Family; SubspaceId was an enum of Alfie, Betty, Gemma etc. The sometimes tricky aspect of this was making sure that these simple parameters weren't too simple and actually tested the properties of Willow. And some end can't be simple, like the parameters for private area intersection.

So I suggest there's two ways we can go with this: either devise a minimally viable set of parameters for use in testing, or use a real set of parameters, e.g. Earthstar's.

[mycognosist]

We could probably benefit from using rstest in these cases. It provides a neat means of creating test fixtures and parametrised tests. There are lots of good usage examples in the p2panda codebase 🐼

[AljoschaMeyer]

Not sure if rstest helps too much with supplying choices type parameters ("generics"), though.

[sgwilym]

We could probably benefit from using rstest in these cases. It provides a neat means of creating test fixtures and parametrised tests. There are lots of good usage examples in the p2panda codebase 🐼

This question isn't so much about setting up specific states with reusable items (e.g. give me a Store with all the entries for a chat between Alfie and Betty in it), but about something lower than that: in order to test any fixtures at all we need to
decide which parameters Willow uses (e.g. that a SubspaceId can be Alfie or Betty). These parameters need to be 'real' enough to adequately test Willow's qualities. For instance, whatever we use for the is_authorised_write parameter needs to succeed or fail based on the entry used and the token given and can't just be () => true.

So my question is: do we do what willow-js does (fantasy protocol with reasonable constraints) or just use Earthstar's parameters, which are all defined already?

• Using fantasy parameters is faster, but the expediency may lead to blind spots in our tests.
• Using Earthstar's parameters would be some more upfront work (e.g. implementing Cinn25519), but the tests could give us good confidence, and we'd kind of implement Earthstar along the way.

[AljoschaMeyer]

As someone who hopefully won't need to implement any of it, I'd prefer using the Earthstar parameters directly =P