Unit test practices in Phobos

[Jeremie Pelletier]

Andrei Alexandrescu Wrote:

> Jeremie Pelletier wrote:
> > Andrei Alexandrescu Wrote:
> > 
> >> 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
> > 
> > Don't you disable unittests in release builds?
> 
> Phobos has the builds: debug, release, unittest/debug, and 
> unittest/release. Client apps use the release version. I like being able 
>   to unittest the release version to make sure that the optimizer etc. 
> don't do shenanigans.
> 
> Andrei

Oh yeah I just did a test compile with -O -release -inline -unittest, took about 30 seconds to compile.

Still this is lightning fast when compared to C. Even using make with 40 jobs on my quad core a lot of programs take minutes to compile, DMD does it all in one big swoop, no jobs needed, no makefile needed.