Named unittests

Johannes Pfau via Digitalmars-d digitalmars-d at puremagic.com
Tue Mar 31 07:27:39 PDT 2015


Am Tue, 31 Mar 2015 13:31:58 +0000
schrieb "Dicebot" <public at dicebot.lv>:

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

Yes, one array of TestAttribute[]
struct TestAttribute
{
    TypeInfo ti;
    void* value;
}
per unittest and an array of unittests in ModuleInfo would likely work.

But this works only for unittests and it's still restricted*. I'd prefer
a more general solution which also works for benchmarks and similar
usecases.

*For example you can extract file/line
information (useful for IDEs) but you'll have to add explicit @fileline
UDAs to the tests. With compile-time reflection you can gather this
information without additional UDAs.


More information about the Digitalmars-d mailing list