On Monday, 30 April 2012 at 03:16:57 UTC, Alex Rønne Petersen
wrote:
The problem with D's unit test support is that it doesn't
integrate well into real world build processes. I usually have
debug and release configurations, and that's it. No test
configuration; not only does that over-complicate things, but
it also isn't really useful. I want my unit testing to be
exhaustive; i.e. I want to test my code in debug and release
builds, because those are the builds people are going to be
using. Not a test build.
So, this means that writing unit tests inline is a no-go
because that would require either always building with unit
tests in all configurations (madness) or having a test
configuration (see above).
Given the above, I've resorted to having a "tester" executable
which links in all libraries in my project and tests every
module. This means that I have to write my unit tests inside
this helper executable, making much of the gain in D's unittest
blocks go away.
And no, the fact that I link libraries into the helper
executable doesn't mean that I can just write the unit tests in
the libraries in the first place. Doing so would require
building them twice: Once for the normal build and once for the
"tester" executable.
OK, that makes sense. What a test framework could do, although
it's kind of ugly, is first copy the unittest() sections into
separate test files, compile them and then link with the tested
module code.
You would keep the advantage of having test code close to source
code, and still compile the real code without -unittest switch.
(And yes, build times matter when your project gets large
enough, even in D.)
Just for information, how big is your project (how many files),
and how long does a full build take ? I have no idea how fast the
compiler really is (is it GDC or DMD you are using ?).
