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
