Named unittests

Dicebot via Digitalmars-d digitalmars-d at puremagic.com
Tue Mar 31 07:40:40 PDT 2015


On Tuesday, 31 March 2015 at 14:27:45 UTC, Johannes Pfau wrote:
> 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.

Problem with more generic solution is that it is also note 
demanding and potentially more intrusive - right now UDA don't 
affect actual types at all. I'd prefer something simple and 
practical that can work for texts right now - those are special 
enough case to justify dedicated approach (even if generic rtinfo 
gets added later)


More information about the Digitalmars-d mailing list