[dhardy]

Port MockAddRng from my branch, but without SeedingRng impl and slightly different tests

I'm not quite sure on the name or whether it should be seedable, but amazingly this saves 5 independent implementations of RngCore in tests.

[pitdicker]

Great! Surprising the resulting line count is only 10 less.

What do you think about moving it inside the test module in lib.rs?

[clarfonthey]

Why not just StepRng?

[dhardy]

It could be moved to the test module for internal use only, but it may well be useful to other users too.

@clarcharr the first time I tried introducing this I got criticized for not making it very clear from the name that it was not a real random number generator, though I guess mock::StepRng or test::StepRng should be good enough.

[clarfonthey]

@dhardy Honestly, I think that the docs are plenty, and that the name is unwieldy otherwise.

[dhardy]

Renamed as suggested.

@pitdicker about 30 of the new lines are documentation. If put directly in the test module it would drop that. But is it not useful enough to be worth exporting? I wonder if we should have a rand-mock crate in the future — but perhaps better not to have too many tiny crates.

Edit: rebased to clean up and fix doc

[pitdicker]

O, the number of lines was no critique, just an observation 😄.

But is it not useful enough to be worth exporting?

I don't know. It could be useful for some tests. But you would have to know quite some details of the implementation to use it when also using ranges, floats, distributions etc.

Crazy idea: what do you think about making it conditionally available with cfg(debug_assertions)? Then it will not accidentally end up in the code in release builds.

[dhardy]

I've been thinking about putting more stuff behind feature flags. We could have a "mock" feature flag then put this behind #[cfg(any(test, features="mock"))].

But, true, this is mostly useful for testing distribution implementations, and many of them are in rand already, so maybe better not to export.

Edit: I realise there's not much point using a feature gate since the linker removes any unused components anyway; besides it complicates documentation. I don't see a "guard" against use in release builds as helping much anyway.