You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Soroban's fuzzing support is all located in the soroban-sdk crate, end-user focused. It could be desirable for internal testing purposes to have that support in the soroban-env-host crate, or even soroban-env-common, with implementations of SorobanArbitrary for the internal types used by the host but not exposed through the SDK.
What would you like to see?
Extract most of soroban_sdk::arbitrary to soroban_env_host::arbitrary (or soroban_env_common::arbitrary), and reexport from the SDK.
The big complication is that the main SorobanArbitrary type is defined in terms of the Env struct that is defined in the SDK, so not suitable as-is for use in the env crates. It may not be possible to simply move it.
What alternatives are there?
The main desire I think is probably to write proptests for the env crates, and the Arbitrary trait is not strictly necessary for proptests, and using it as intermediary for proptests may even result in lower quality input than just using the proptest traits directly.
It might be desirable to instead write proptest adapters directly, in a similar way to the SorobanArbitrary prototype.
What problem does your feature solve?
Soroban's fuzzing support is all located in the soroban-sdk crate, end-user focused. It could be desirable for internal testing purposes to have that support in the soroban-env-host crate, or even soroban-env-common, with implementations of SorobanArbitrary for the internal types used by the host but not exposed through the SDK.
What would you like to see?
Extract most of soroban_sdk::arbitrary to soroban_env_host::arbitrary (or soroban_env_common::arbitrary), and reexport from the SDK.
The big complication is that the main SorobanArbitrary type is defined in terms of the Env struct that is defined in the SDK, so not suitable as-is for use in the env crates. It may not be possible to simply move it.
What alternatives are there?
The main desire I think is probably to write proptests for the env crates, and the Arbitrary trait is not strictly necessary for proptests, and using it as intermediary for proptests may even result in lower quality input than just using the proptest traits directly.
It might be desirable to instead write proptest adapters directly, in a similar way to the SorobanArbitrary prototype.
cc @graydon
The text was updated successfully, but these errors were encountered: