Does D have too many features?

[Alex Rønne Petersen]

On 30-04-2012 05:12, Jonathan M Davis wrote:
> 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

Except we can't do:

@test
void myTest()
{
     // ...
}

due to the current lack of annotations and discovery-based reflection. ;)

*hint hint...*

-- 
- Alex