Move arbitrary module into testutils module #1131
Comments
|
No reason. I just hadn't considered putting it there. I'm ok with moving it. There's one it soroban-env-common as well. If this one moves, that one seemingly should too, though I don't think there is a corresponding testutils mod there. (edit: though the one in inv-common is not part of the public interface of that crate). |
|
It may also be reasonable to hide the One of the things the arbitrary module reexports is the arbitrary crate, creating Edit: The arbitrary module does contain a bunch of mod-level docs, so removing it would require relocating them somewhere. |
### What Move the arbitrary module under the testutils module. FIxes #1131 ### Why All other testutils features are under the testutils module. ### Known limitations This does not leave a deprecated module of reexports in the old location, so fuzz users will experience breakage. The soroban-examples repo and the fuzzing tutorial will need to be updated. There is other possible restructuring of the arbitrary module that could also be done, but is not, e.g. the contents of `arbitrary` could be reexported directly under `testutils`. This leaves the private `arbitrary_extra` module in its current location. `soroban-env-common` has a corresponding `arbitrary` module, but it is private. Now these two crates will have their corresponding modules located in different places. --- I also updated the lockfile for tests/fuzz/fuzz, as Cargo seems to want it updated. --------- Co-authored-by: Leigh McCulloch <351529+leighmcculloch@users.noreply.github.com>
The arbitrary module is only intended for use when testutils are enabled. We have most testutils organized under a testutils module. The arbitrary module seems to be the exception where it lives at the top-level.
Was there a reason we didn't want it to be inside testutils? @brson Do you remember?
If there's no reason, would anyone be opposed to moving it under testutils?
The text was updated successfully, but these errors were encountered: