Named unittests

[Atila Neves via Digitalmars-d]

On Tuesday, 31 March 2015 at 14:13:29 UTC, Johannes Pfau wrote:
> 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.

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.