Does D have too many features?
deadalnix
deadalnix at gmail.com
Mon Apr 30 05:25:02 PDT 2012
Le 30/04/2012 05:03, H. S. Teoh a écrit :
> 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.
>
Is @unittest on top of a function much more difficult ?
> 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.
>
Agreed.
> 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.
>
Consider cases like checking if Liskov substitution principle is
fallowed in a class hierarchy running the same unitest on various
instantiations in that hierarchy.
This is common need and still fall in the unittest bag.
More information about the Digitalmars-d
mailing list