Does D have too many features?

[Jacob Carlborg]

On 2012-04-30 05:16, Alex Rønne Petersen wrote:
> On 30-04-2012 05:03, 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.
>>
>>
>> T
>>
>
> 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.
>
> (And yes, build times matter when your project gets large enough, even
> in D.)
>


-- 
/Jacob Carlborg