glossy ridge
Recently I have been working on making it possible to fuzz Soroban contracts. Having some progress and experience now, I am writing up what I have learned and prototyped in hopes of getting feedback.
It's pretty long to write out here, so it's in this gist:
https://gist.github.com/brson/7b09b4564250017483a483c4bbe043c9
I'm hoping to get some indication of what people think of this direction.
mighty eagle
I saw a todo in the code about soroban-auth. It may not be worth implementing any of the types in the soroban-auth package, if that's not done yet, because @calm anchor has a proposal for auth that will deprecate the soroban-auth crate.
Nice idea with how to get from types that have no dependence on Env, to the SDK types 👏🏻.
It seems desirable for contract authors to write contracts in terms of the contract types, and not think about the serialized form of the type and why they should be converting between the two to write fuzz tests.
...
In some of the Arbitrary implementations I have written, namely Static and Status, I do first create the corresponding XDR type and convert it to the contract type, but I don't expose that detail in the interface.
I think this approach of hiding the fact that the XDR types are used as an implementation detail is 
. We do a similar thing with signing test utilities where a user doesn't need to know about the XDR types, but we use XDR types under-the-hood.
I left some comments replying to questions in the gist itself:
https://gist.github.com/brson/7b09b4564250017483a483c4bbe043c9?permalink_comment_id=4431320#gistcomment-4431320
https://gist.github.com/brson/7b09b4564250017483a483c4bbe043c9?permalink_comment_id=4431323#gistcomment-4431323