Am Tue, 31 Mar 2015 13:31:58 +0000 schrieb "Dicebot" <pub...@dicebot.lv>:
> > But here's the problem: > > > > 1) The compile time approach requires some kind > > of explicit registration of the unittests. At least one > > mixin per > > module. > > 2) This mixin will usually provide a module constructor. But > > using module constructors will cause issues with cycle > > detection. > > This is not really true. You only need one mixin in the root > module(s), rest can be iterated recursively by test runner itself > using __traits(allMembers) reflection. Only issue with that > approach is that last time I checked there was a DMD bug which > prevented from getting complete list of imported modules via > allMembers. Should be fixable. But then you still have to explicitly import (or at least name) all modules that should be tested. This is a drawback compared to the current builtin-unittests where you do not have to explicitly import to-be-tested modules. I was thinking of a fully-automated way where you only have to import a module (could even be object-d => no explicit import required) and have all tests run. This can be done by mixing in a module constructor in every module. From that constructor you'd call std.unittest.registerTest(...) and in the main function you could then call std.unittest.runTests(). This way you never need to name or know the tested modules. IIRC std.benchmark used that approach, with the drawback of manual mixins and module constructor cycle issues. > > And module constructors are not needed at all for this, there is > http://dlang.org/traits.html#getUnitTests Sure, but I was thinking about a runtime registration scheme as explained above.