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
