[collyw]

I would argue the opposite. Running a passing test over and over again when a piece of code hasn't changed doesn't actually gain you anything (though if you are refactoring it will). Using randomness will test a lot more cases.

[egeozcan]

You can generate random test cases (and save them), given that you have no performance worries. However, introducing randomness inside a test doesn't make so much sense, as one of the grandparents states, because the point of testing is predictability. When a test which does things differently every time it runs fails once, it is not totally useless information but much less informative than a test which always fails.

I should also mention that there are a lot of cases where randomness wouldn't affect the result[1], but then, why introduce randomness in the first place?

If the aim is to test as many combinations of different variables as possible, bunch of tight, nested loops would be much reliable IMHO.

[1] for example, if a list doesn't render correctly with n elements, it is very likely that it still wouldn't with m elements - unless you have performance problems and that means you need to test for the maximum sane values and limit the input

[matthewmacleod]

You're right, but I would at least class that as a different sort of testing – it's much closer to e.g. fuzzing than unit testing. Both are valuable though.

[vkjv]

My thoughts exactly. Randomness has a place in tests, but not in unit tests.