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