Unless you are writing an actual random number generator or some kind of encryption library that relies on secure random number generators you don't need to check that if the random number generator is biased or not. That is the job of the author of the Random number generator.
Your example of Collections.shuffle()
is also a poor example because it is a built in JDK method. There's no reason to test a built-in JDK method, the authors of Java have done that already for you plus the millions of users who have used these methods over the past 20 years. Do you also have tests to confirm System.out.print()
works as expected too?
Unit tests are supposed to be deterministic. Rerunning the same test over and over again should produce the same results EVERY time. If they don't and the test fails, is it failing because the code is buggy or because the non-deterministic output produced invalid input? If when rerunning the results, the tests pass, is it because the bug was fixed or because we happened to get random input that worked?
For these reasons, your unit tests should try to mock or stub out any randomness. Perhaps write several tests that perform specific transformations of the data to test boundary conditions. For example, for shuffle()
maybe have a test that reorders the elements in a specific order or sorts the elements in ascending or descending order or a test that doesn't actually do any transformation etc. These are all valid results that could happen randomly.
This way the tests all produce the same output for the same input everytime and you get the benefit of different results.
EDIT
It appears you actually want to test your own random number generator.
Here are links that describe statistical tests you should do to see if it is really random (or at least as random as possible)
RANDOM.ORG statistical analysis
NIST statistical test suite