I quote from http://xunitpatterns.com/Generated%20Value.html

Variation: Random Generated Value

One way to get good test coverage without spending a lot of time analyzing the behavior and generating test conditions is to use different values each time we run the tests. Using a Random Generated Value is one way to do this. While this may seem like a good idea, it makes the tests non-deterministic and can make debugging failed tests very difficult. Ideally, when a test fails, we want to be able to repeat that test failure on demand. This can be made possible by logging the Random Generated Value as the test is run and showing it as part of the test failure. We then need to find a way to force the test to use that value when we are troubleshooting the failed test. In most cases all this is too much effort for the potential benefit but when we need this technique, we really need it.

If you have identified your test cases with adequate thoroughness, you would not need randomness. Every variant that could produce a different result is tested. Code coverage analysis helps in this regard.

But with a sufficiently complex process that you are testing, having 100% code coverage does not mean that you are bug free. Using random input data, and knowing what the correct output should be, is a form of model-based testing, and it is valid.

Another approach that is more methodical is to generate every possible permutation of inputs (assuming that there are not an infinite number of them) and doing so programmatically, and using your model to know the expected output. Then, you can generate your test cases.

Sometimes, though, you can filter this down significantly by using equivalence classes.

Still other times, knowing what kind of data may get thrown at your code is hard to predict. Analysis of production data helps there. Unfortunately, you can seldom test against ALL of production code. And testing a subset means a lot of redundant testing, and the possibility of missing important test cases. In that situation, apply equivalence classes to individual records, and divide the production data into the smallest set of records that gives you representation of every known class of data. I once did this to a nearly half-billion record data set, and the result was around 0.25%. Yes, that’s 1/4th of one percent. There is a lot of redundancy in production data.

Random data = random failure which is very hard to track down.

About the tests with the Theories, I can’t use it to do what you are saying:

The ‘testTheNewTheoriesStuff’ Theory is then executed with each of the values defined in the values array decorated with the @DataPoints annotation.

When I use an array of Objects, the @Test/@Theory will expect an array as parameter in the method….So if I have a array of int as DataPoints, I must use an array of int as parameter in the test….. :/

Can you please let us know how your test method are running without error.
I have used @RunWith(Theories.class) but my test methods are expecting @Theory , if i will annotate with @Test then i am getting errors that test methods should not have any arguments

http://blog.bader-jene.de/?p=30

I wrote a test program using @RunWith(Theories.class) and had few static public variables that act has @Datapoint. I had some parameterized methods and used @Test (instead of @Theory) annotation.

@RunWith(Theories.class)
public class TestCalculatorUsingDataPoints {

Calculator calculator = null;

@DataPoint
public static int first_number = 10;

@DataPoint
public static int second_number = 20;

@Before
public void setUp() {
calculator = new Calculator();
}

@After
public void tearDown() {
calculator = null;
}

@Test
public void add(int number1, int number2) {
int actualResult = calculator.add(number1, number2);
//assertEquals(expectedResult, actualResult);
int expectedResult = number1 + number2;
System.out.println(“add ” + number1 + ” ” + number2);
assertThat(actualResult, is(expectedResult));
}
}

JUnit did not throw any error that @Theory should be used. JUnit recognized the @Test methods and call the same method with each datapoint.

Result:
add 10 10
add 10 20
add 20 10
add 20 20

Isn’t weird?