Am 26.10.2016 um 19:58 schrieb Adam D. Ruppe:
On Wednesday, 26 October 2016 at 17:47:51 UTC, Sönke Ludwig wrote:
I misremembered this as getting called once per module, which would
have been insufficient.
Yeah, I don't love the name either.
But you should be able to set that in a static module ctor in your
library (bonus points, even compare the old against the default and have
a runtime warning about combining two incompatible test libraries) then
go nuts with it.
I think currently the ModuleInfo unittests property combines all of them
into a single function, so to get more granularity, you have to do CT
reflection, which means listing all the modules... which kinda sucks
right now.
It might be nice some day to make that easier. Separate out the runtime
thing to return function array instead of one combined function, and
perhaps some kind of assistance in walking the whole program import graph.
Regardless, unittests without main() should be perfectly doable today!
Yeah, for being able to enumerate the modules, DUB in fact generates a
special module if a custom unit test runner is used (well, actually it
is currently tied to the "tested" runner for historic reasons, which
should really be changed).
