Named unittests

[Dicebot via Digitalmars-d]

On Tuesday, 31 March 2015 at 09:08:47 UTC, Johannes Pfau wrote:
> Am Mon, 30 Mar 2015 14:52:36 -0700
> schrieb Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:
>
>> We're having a strong need for named unittests at Facebook for
>> multiple reasons.

> Right now the default implementation works by putting pointers 
> to a
> test function into ModuleInfo. We could instead add arrays of 
> some
> 'unittest information' struct to ModuleInfo to support names 
> etc. But
> we can't make this as extensible and powerful as it should be: 
> In order
> to support arbitrary UDAs we'd always need some kind of 
> UDA=>runtime
> serialization.

Most powerful solution would be to simply put attributes for 
unittest blocks in runtime information for tests (using RTTI it 
should be possible to define such variadic structure in similar 
manner as D-style variadic function arguments).

> The other option is getting a list of unittests at compile time.
> (__traits allMEmbers, etc). AFAIK all unittest frameworks
> supporting UDA use this approach. This is much more powerful and
> extensible. It might make sense to switch the default 
> implementation.
>
> 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.

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