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?
