Consider moving the generators here and remove the TODO from https://git.frostfs.info/TrueCloudLab/frostfs-node/src/branch/master/pkg/local_object_storage/blobstor/perf_test.go#L257-L402
crypto/rand seems like overkill here. Maybe use golang.org/x/exp/rand instead.
What about we create a TestStorage implementation of common.Storage which can wrap other implementations and passthrough certain calls to the underlying storage while setting some test…
IMHO, any unit test that requires OS interaction is not really "unit" anymore. The thing with those failing tests is that they use some unorthodox way of verifying their behavior, so we should…
Let's add some artificial unit test to show a warning when tests are running under root, at least for debugging purposes for now, since our code is quite entangled with os usage and bbolt itself.
Using fs.FS is not trivial for the following reasons:
- It's only read-only for the time being (https://github.com/golang/go/issues/45757).
- Even if we embed it in an extended interface…
The registry is used also for e.g. delete workload when there are no pregenerated objects. So probably worth keeping it at least for local tests.
done. Turned it into a singleton. (the original reason was that Connect is called multiple times and you can't have more than an instance of the engine running).
Possibly, but this is what all examples were doing so I copy-pasted it blindly. Let's refactor it in a separate PR since it touches a bunch of other files.
Is it possible to use https://pkg.go.dev/io/fs#FS instead of os everywhere? This way we can mock this things without resorting to perm tricks and make at least the unit tests fully hermetic.