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