Does D have too many features?

[SomeDude]

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 ?).