On Tuesday, 31 March 2015 at 14:13:29 UTC, Johannes Pfau wrote:
Am Tue, 31 Mar 2015 13:31:58 +0000
schrieb "Dicebot" <[email protected]>:
> 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.
This is true, but importing modules by name can be code that is
generated. Which is exactly what I do with dtest [1] and
unit-threaded [2]. It's not that big of a deal when it's part of
the build system.
Atila
[1] http://code.dlang.org/my_packages/dtest
[2] http://code.dlang.org/my_packages/unit-threaded
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.
