Low level unit test library in druntime

[Atila Neves via Digitalmars-d]

On Tuesday, 30 August 2016 at 16:31:56 UTC, Dicebot wrote:
> On 08/30/2016 07:17 PM, Jacob Carlborg wrote:
>> The reason to put in the druntime is because that's where the 
>> existing runner is located.
>> 
>> The advantage of this low level library is that:
>> 
>> * Third party unit test library don't need to reinvent the 
>> wheel
>> 
>> * All third party libraries using this low level library would 
>> be compatible and can be combined in the same project
>> 
>> * If we would like to, it would be easy to extend the existing 
>> runner, like not stopping on the first failure. _Not_ saying 
>> that we should
>
> I definitely wouldn't want to use API like you proposed if I 
> was to write my own test runner. Minimal common ground which 
> would be cool to have is getting range/array of all unittest 
> blocks together with their annotations. Anything more than that 
> is optional luxury that specific test systems may define.
>
> And any usage of classes in what is supposed to be a base 
> ground API is immediate "no" for me :)

And never mind that any such low level library would suffer from 
the same problem unit-threaded did until dub fixed it: D can't 
reflect on packages so a program must be written that explicitly 
lists all modules that need to be looked at.

The current situation in druntime with the default runner doesn't 
work either because all unit tests end up being a single function 
pointer from the module.

There's a disconnect between what's possible at runtime with 
ModuleInfo and what's possible at compile-time with 
__traits(getUnittests). Fortunately for me, running unit-threaded 
itself as an executable with dub fixed the problem, but in the 
general case this proposal would suffer from the same problems. 
Unless we force everyone to use dub.

Atila