unittesting generic functions

[Idan Arye via Digitalmars-d]

On Friday, 15 August 2014 at 00:52:35 UTC, Andrei Alexandrescu 
wrote:
> On 8/14/14, 3:46 PM, H. S. Teoh via Digitalmars-d wrote:
>> Having only .init guaranteed to exist for a generic type T (and
>> sometimes not even that if you have a Voldemort) greatly 
>> cripples the
>> utility of the unittest.
>
> I'm thinking of T.random as a sort of generator of random 
> correct objects of type T...
>
> Andrei

So now every type will need to declare a way for randomly 
instances of it?

At any rate, random is bad for unit testing. Unit tests need to 
be deterministic, because when a unit test fails you want to 
debug it to see what's wrong. If the unit test generates some 
random data, in your debug it'll probably generate different data 
than the one it generated when the test failed, and the problem 
may or may not repeat.

Of course, you can always use a random function with a predefined 
seed to solve that, but there are more problems yet. Unit tests 
usually operate by setting up the data, calling a function, and 
testing it's result and/or side-effects. If you set up the data 
by hand, you know what the results and side-effects are supposed 
to be.

For example, let's take a look at the example unit test for 
CRC(http://dlang.org/phobos/std_digest_crc.html#CRC32):

     //Simple example, hashing a string using crc32Of helper 
function
     ubyte[4] hash = crc32Of("abc");
     //Let's get a hash string
     assert(crcHexString(hash) == "352441C2");

Here, we know what the result is supposed to be, because we can 
calculate it manually(or with external tools that we know they 
are correct) and write the literal result in the unit test. But 
How will you check that `crc32Of(string.random())` returns a 
correct result?