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 <[email protected]>:
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
