Provide random values

[nipafx]

Support use cases for random values, e.g. as parameters (like this; inspired by junit-team/junit5#839) or fields or arguments for parameterized tests.

[sormuras]

And/or as a simple ParameterResolver implementation show-cased by the junit5-sample:

Usage could look like:

@ExtendWith(RandomParametersExtension.class)
class RandomParametersExtensionTests {
  @Test
  void injectsInteger(@Random int i, @Random int j) { assertNotEquals(i, j); }
  @Test
  void injectsDouble(@Random double d) { assertEquals(0.0, d, 1.0); }
}

[nipafx]

My personal opinion is that however this is implemented, it should be possible to repeat the tests with the same random values. That makes it necessary:

• to have a deterministic entry point that spits out the seed value that is used
• to allow configuration of that entry point to pass the seed to it

As far as I see it (and as long as JUnit does not randomize test order), the only challenge for the deterministic entry point is multi-threading. I am willing to accept that limitation.

Speaking of randomizing test order, it would be interesting to find out whether an extension could do that.

[sormuras]

[...] repeat the tests with the same random values.

@Random(seed = 123) should suffice. When running with the default @Random it could be reported via the TestReporter facility.

Speaking of randomizing test order, it would be interesting to find out whether an extension could do that.

junit-team/junit5#13 is still open...

[nipafx]

Possible features:

• set seed per class
• set seed globally via configuration parameter

[Michael1993]

I don't see the use-case for this. You should always control your input to your tests which means no randomizing.

[Bukama]

I don't see the use-case for this. You should always control your input to your tests which means no randomizing.

I'm with @Michael1993.

• If I don't need a value for my method I can pass whatever class type of the parameter / class under test allows (null, default, any number, etc.)
• If I want to check for edge cases code coverage tools like JaCoCo or mutation testing tools like PIT take this spot
• If I really want to use random values, we don't have to reinvent the wheel, as there are plenty of property based testing tools like jqwik

So I vote to close this issue.

[beatngu13]

I don't see the use-case for this. You should always control your input to your tests which means no randomizing.

Actually, random testing is quite a big thing. Be it at the top of the test automation pyramid (e.g. Sapienz) or at the bottom (e.g. QuickCheck).

However, let's not get too philosophical. 😉 I agree with @Bukama that we shouldn't do this, there are excellent libs already available. I think this is out of scope and would open a can of worms. Therefore, I also vote to close this issue.

[nipafx]

Whoa, why does everybody want to close this? No random values in tests? Where's your sense of adventure? 🚀

I'd still like to implement this eventually:

• there is an actual JUnit user asking for this feature
• with a seed, the randomness is reproducible, so there's no disadvantage
• switching to a different test engine or even entire testing tool has a slightly bigger foot print than adding an extension
• it sounds like fun!

Vote not to close 😜

[nipafx]

I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may.

Introduce a little anarchy. Upset the established order and everything becomes chaos. I'm an agent of chaos. Oh, and you know the thing about chaos? It's fair.

Why so serious? 🃏

Yes, quoting Tyler Durden and the Joker is juvenile and both are full of shit, but... it's fun. :)

[nipafx]

I also just now realize that it may be interesting to think about this in terms of parameterized tests:

• this could be a source for parameterized test arguments
• this could be a test template of its own, spawning a preconfigured number of tests with random parameters

I'm gonna unilaterally green-light this. 😁

[nipafx]

To be a good issue for first contributors, this issue should describe the specific annotations to be created as well as give a rough idea how to implement them.

[keturn]

When you get to the point of wanting to have reproducible runs, this looks like it might be of use: java.util.SplittableRandom

[nipafx]

In lieu of fleshing out this issue, I created a proof of concept. 😁

[nipafx]

I think the best use for this extension is to become part of the revamped Cartesian product extension, so I don't think it makes sense to invest more time here before #415 is done.

[tubbynl]

In randomizing data JavaFaker (https://github.com/DiUS/java-faker) does provide sensible random data, in combination with parameterized tests you do get valuable edge-case information.

Certainly when testing validation stuff.