On Sunday, April 29, 2012 20:03:44 H. S. Teoh wrote:
> On Sun, Apr 29, 2012 at 11:39:02PM +0200, deadalnix wrote:
> > Le 29/04/2012 22:54, Alex Rønne Petersen a écrit :
> > >D unit tests were never really useful for anything beyond
> > >single-library projects IMHO. They don't scale for large, real-world
> > >application projects with lots of libraries and executables.
> >
> > +1 A good std.unittest + attributes is probably a better approach.
>
> The only reason I actually write unittests for D code is because
> unittest{} is so convenient. If I had to import std.unittest, most
> likely my code will have no unittests at all.
>
> I find that because unittest{} makes it so convenient to write
> unittests, it's just embarrassing to not write them. Which is kinda the
> point, 'cos in my experience the act of writing a unittest automatically
> makes you think about corner cases in the code you just wrote (or just
> about to write), which means there will be less bugs from the get-go.
>
> 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.
One common term for those is "component tests." Unit tests are for testing
individual functions and types, whereas component tests test inter-module and
inter-program interactions.
What D has with regards to unit tests works _very_ well for basic unit tests
but does not attempt to support component tests at all beyond where unittest
blocks could be used for the same purpose. The main place that D's unit test
framework becomes problematic is when you need to run a subset of tests - it's
designed to run everything at once. But compiling and running each module
separately for unit tests allows you to control that through you build system
or whatnot.
As Walter has stated on several occasions, D's built-in unit testing framework
is designed to be incredibly simple and easy so that they're so easy and
convenient to use that you have no excuse not to. If you want more complicated
unit testing frameworks, there's nothing stopping you from making your own
like has to be done in other languges. For instance, cppunit and junit aren't
built-in to their associated languages at all; they're 3rd party projects. You
can do the same in D if you want fancier unit testing facilities.
- Jonathan M Davis
