Does D have too many features?

H. S. Teoh hsteoh at quickfur.ath.cx
Sun Apr 29 21:56:08 PDT 2012


On Mon, Apr 30, 2012 at 05:16:55AM +0200, Alex Rønne Petersen wrote:
> On 30-04-2012 05:03, H. S. Teoh wrote:
[...]
> >Also, unittest is just that: for _unit_ tests. If you start needing
> >an entire framework for them, then you're no longer talking about
> >_unit_ tests, you're talking about module- or package-level testing
> >frameworks, and you should be using something more suitable for that,
> >not unittest.
[...]
> 
> 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.

I see. Personally, I just use a more flexible build system where I can
specify an argument to indicate whether or not to compile with
-unittest. But you may have other reasons why this is not a good thing.


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

I wonder if dmd (or rdmd) should have a mode where it *only* compiles
unittest code (i.e., no main() -- the resulting exe just runs unittests
and nothing else).

But then again, it sounds like you have an extensive testing framework
in place, and if you have that already, then might as well use it.


> 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.
> 
> (And yes, build times matter when your project gets large enough, even
> in D.)
[...]

True.


T

-- 
"I speak better English than this villain Bush" -- Mohammed Saeed al-Sahaf, Iraqi Minister of Information


More information about the Digitalmars-d mailing list