On Tuesday, 16 February 2016 at 22:13:15 UTC, Sebastiaan Koppe wrote: > On Monday, 8 February 2016 at 13:23:40 UTC, Atila Neves wrote: >> What's new: >> >> [...] >> >> Enjoy! >> >> Atila > > I just started using unit-threaded and I like it so far, specially the parallel runner. Just had some speed-bumps that might be worth noting. > > Before going into details I want to mention that I am not using it the way it is supposed to be used, which voids me from warranty I suppose. > > From what I gather the normal way would be to create separate test-files with test-cases and unittest blocks inside them, completely separate from normal code. > > Two things that made me go in the opposite direction was dub and code coverage. > > So I don't have separate test files; I have the unittest blocks interspersed with code. Because I don't want to include unit_threaded in production code I ended up doing this: > > version (unittest) > { > include unit_threaded; > @Name("Test test") > unittest > { > ... > } > } > > Which is redundant, but I need the import outside the unittest for the UDA, and I don't want the import to show up in production code. > > Then to get `dub test` to run unit_threaded I had to create a small program that discovers all modules and generates a testrunner.d file in the source directory, which gets picked up by dub. So now instead of `dub test` I call `rdmd test.d`, which generates the testrunner.d and calls dub test. > > I feel I am going against the grain here. I'm on a tablet on holiday so sorry in advance for the short answer. Your versioned import is the reason why I made it so a plain string UDA is just as good as @Name. That way you only need to import unit_threaded once in a version block, and only if you want to use the shouldXXX assertions. The test runner you mentioned can be generated by using my dtest tool, also on dub. The next thing on my TODO list is to make it even easier to opt-in to using unit-threaded without having to change existing project code Atila