It seems that in many unit tests, the values that parameterize the test are either baked in to the test themselves, or declared in a predetermined way.

For example, here is a test taken from nUnit's unit tests (EqualsFixture.cs):

[Test]
public void Int() 
{
    int val = 1;
    int expected = val;
    int actual = val;

    Assert.IsTrue(expected == actual);
    Assert.AreEqual(expected, actual);
}

This has the advantage of being deterministic; if you run the test once, and it fails, it will continue to fail until the code is fixed. However, you end up only testing a limited set of values.

I can't help but feel like this is a waste, though; the exact same test is probably run with the exact same parameters hundreds if not thousands of times across the life of a project.

What about randomizing as much input to all unit tests as possible, so that each run has a shot of revealing something new?

In the previous example, perhaps:

[Test]
public void Int() 
{
    Random rnd = new Random();
    int val = rnd.Next();
    int expected = val;
    int actual = val;
    Console.WriteLine("val is {0}", val);
    Assert.IsTrue(expected == actual);
    Assert.AreEqual(expected, actual);
}

(If the code expected a string, perhaps a random string known to be valid for the particular function could be used each time)

The benefit would be that the more times you run a test, the much larger set of possible values you know it can handle correctly.

Is this useful? Evil? Are there drawbacks to this? Am I completely missing the point of unit testing?

Thank you for your thoughts.

c# unit-testing
Edit
Report