Named unittests

[Johannes Pfau via Digitalmars-d]

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.
> 

As there have already been suggestions to use UDAs I think we should
discuss the fundamental difficulty with unittests:

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.

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.

There are some similar usecases with exactly the same issues (benchmark
functions, ...). So we'd need a general solution for this.


One possible solution for problem 1 would be to have mixins that
automatically get mixed in once at module scope in imported modules (a
little bit like RTInfo):

-----------------------
module benchmark;

@automodule mixin template Foo()
{
    shared static this() @nocycle
    {
        //traits allmembers, ...
    }
}
-----------------------
module test;
import benchmark; //=> automatically inserts mixin Foo;
-----------------------

To solve problem problem 2 a nocycle UDA could be used to ignore
cycle checking (or @depends("benchmark") to only list explicit
dependencies).