Depends on D4164
Adding tools with one function: generate_nbytes. It returns n bytes (that are the same).
Differential D4225
[services] Tests - Add tools • karol on Jun 7 2022, 6:49 AM. Authored by Tags None Referenced Files
Details
Depends on D4164 Adding tools with one function: generate_nbytes. It returns n bytes (that are the same). this doesn't do anything on its own. Tests can be built.
Diff Detail
Event TimelineComment Actions It's true we can replace this function inline with just vec![n, b] but using such a named function is more readable for me. If you feel like it's useless, we can abandon.
Comment Actions I don't think this function is really useful, because as you said, we can just use vec![n, b]. One option to make it a better is to consider generating random bytes: we can use seedable random to make tests repeatable. Comment Actions I think we should generate random bytes. You can do something like this: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=3d609eb08cf49a2d3a97ca9a6599786b Some other notes:
Comment Actions
Not sure if generating pure random data is a good idea as it makes tests not repeatable. Instead, we can use seedable random, which uses a seed that can be hardcoded and based on that generates the same result for every test call. Comment Actions Good point. this crate makes it easy to create a thread-local rng from a seed. https://github.com/smol-rs/fastrand#examples Comment Actions As for the random data - the specific reason why I didn't want to use random data is that it takes really a lot of time to fill bigger buffers with random bytes. Filling just with, let's say, one hardcoded byte is much more efficient. And in these tests, eventually, we'll want to test mega and giga-bytes-long pieces of data. I remember in c++ it took too long to fill a couple of GB with random data. With that said, I'm down to try to replace just mocking one byte and filling the buffer with random data. We could resign from this function, but please note, that it's going to be easier to maintain this code. If we ever want to replace this logic with, for example, random bytes, we'll just need to replace the code in this one function. When using inline replacements, we'll have to find every place in which we do this operation.
Comment Actions If the Error enum variants here are relevant to all the test functions, then I'm ok with this.
|
I'm not a Rust expert, but seems confusing to "shadow" the existing variable named c with another variable named c