Named unittests

[Johannes Pfau via Digitalmars-d]

Am Tue, 31 Mar 2015 13:31:58 +0000
schrieb "Dicebot" <public at dicebot.lv>:

> > But here's the problem:
> >
> > 1) The compile time approach requires some kind
> >    of explicit registration of the unittests. At least one 
> > mixin per
> >    module.
> > 2) This mixin will usually provide a module constructor. But
> >    using module constructors will cause issues with cycle 
> > detection.
> 
> This is not really true. You only need one mixin in the root 
> module(s), rest can be iterated recursively by test runner itself 
> using __traits(allMembers) reflection. Only issue with that 
> approach is that last time I checked there was a DMD bug which 
> prevented from getting complete list of imported modules via 
> allMembers. Should be fixable.

But then you still have to explicitly import (or at least name) all
modules that should be tested. This is a drawback compared to the
current builtin-unittests where you do not have to explicitly import
to-be-tested modules.

I was thinking of a fully-automated way where you only have to import a
module (could even be object-d => no explicit import required) and
have all tests run. This can be done by mixing in a module constructor
in every module. From that constructor you'd call
std.unittest.registerTest(...) and in the main function you could then
call std.unittest.runTests(). This way you never need to name or know
the tested modules.

IIRC std.benchmark used that approach, with the drawback of manual
mixins and module constructor cycle issues.

> 
> And module constructors are not needed at all for this, there is 
> http://dlang.org/traits.html#getUnitTests

Sure, but I was thinking about a runtime registration scheme as
explained above.