Unit test practices in Phobos

[Andrei Alexandrescu]

Jeremie Pelletier wrote:
> Lars T. Kyllingstad Wrote:
> 
>> I just filed a bug report (3240) that describes a case where IFTI is 
>> used in Phobos, and where this causes errors when the function is used 
>> with a different type than the one used in the unittest. (The well known 
>> "IFTI doesn't work with implicit conversions" problem.) I have a strong 
>> suspicion that there are many other cases like this waiting to be 
>> discovered.
>>
>> I have encountered such errors in my own code many times, and lately 
>> I've been trying to get into the habit of writing unittests for all (or 
>> at least more than one) types. Not full-fledged functionality tests, 
>> mind you -- something like this is usually sufficient:
>>
>>    T foo(T)(T x) if (isFloatingPoint!T) { return x + 1.0; }
>>
>>    unittest
>>    {
>>        // Test different types
>>        alias foo!float foo_float;
>>        alias foo!double foo_double;
>>        alias foo!real foo_real;
>>
>>        // Test functionality
>>        assert (foo(2.0) == 3.0);
>>    }
>>
>> For the cases where any type is allowed (or a lot of them, at least) 
>> even this can become a time-consuming task. In these cases it should at 
>> least be possible to make a representative selection of types to check.
>>
>> I just wanted to recommend this as "good practice" to all, but 
>> especially to the Phobos authors. In my experience this catches a lot of 
>> bugs which are otherwise hard to spot.
>>
>> -Lars
> 
> I just go with type tuples:
> 
> T foo(T)(T x) if(isFloatingPoint!T) { return x + 1.0; }
> unittest {
>     foreach(T; allFloatingPointTuple) assert(foo!T(1.0) == 2.0);
> }

Yah, same here. I have unit tests in Phobos that have nested loops 
testing against so many types, the release build takes forever. Some 
edge case for the optimizer. I must disable them in release builds.


Andrei