[phobos] Split std.datetime in two?

[spir]

On 02/11/2011 12:34 AM, Jonathan M Davis wrote:
> On Thursday, February 10, 2011 15:00:50 spir wrote:
>> On 02/10/2011 11:02 PM, Andrei Alexandrescu wrote:
>>> On 2/10/11 3:44 PM, Don Clugston wrote:
>>>> (1) There has to be a maximum acceptable source file size.
>>>> Personally I start to feel uncomfortable above 2000 lines, and get an
>>>> uncontrollable urge to split at 5000 lines. That's just me, but I
>>>> suggest all modules should be short. And at 35000 lines,
>>>> std.datetime.length>  short.max.
>>>
>>> Agreed.
>>>
>>>> (2) Actually, it seems that most of size actually comes because every
>>>> test is written 'by hand'. If they were done as arrays [parameter1,
>>>> parameter2, result]...
>>>> with a loop, they'd be a lot shorter. (I crunched down the
>>>> std.math.exp tests enormously by doing this). Looking at that module,
>>>> I get the feeling that there's been a lot of cut-and-paste.
>>>> It is a little disconcerting if D really cannot write unittesting code
>>>> concisely. If it really needs to be that big, that part of the
>>>> language needs more work; or we need more helper functions. Or both.
>>>
>>> Agreed. People will look at Phobos for inspiration in terms of style and
>>> idioms. If they see they're looking at more than 2x the size of the code
>>> for adding tests, probably they'd feel intimidated.
>>>
>>> Peeking at std.datetime's unittests, I confirm they are very repetitive -
>>> essentially unrolled loops. I just set the bar somewhat halfway and saw
>>> the following. I mean come on!
>>>
>>>
>>> Andrei
>>>
>>> assertThrown!DateTimeException(Date.fromISOString(""));
>>> assertThrown!DateTimeException(Date.fromISOString("990704"));
>>> assertThrown!DateTimeException(Date.fromISOString("0100704"));
>>> assertThrown!DateTimeException(Date.fromISOString("2010070"));
>>> assertThrown!DateTimeException(Date.fromISOString("2010070 "));
>>> [...]
>>
>> I'm interested in this example. I mean how can this happen? What we would
>> never do in regular (if only because we're lazy, and even copy+paste sucks
>> for more than a few repetitions), we happily do as soon as the /context/
>> is somehow different; eg unittests. Just like if unittest were not code.
>> I've read similar patterns in code by very high-level programmers. There
>> are even test-case generating tools that produce such code.
>
> Unit tests need to be simple. If they're more complicated, the risk of getting
> them wrong goes up. Also, as Steve points out, determining _what_ failed can be
> a royal pain when you try and put something in a loop. Helper functions help
> with that, but it's still a pain.
>
> Normal code can afford to be more complex - _especially_ if it's well unit
> tested. But if you make complicated unit tests, then pretty soon you have a
> major burden in making sure that your tests are correct rather than your code.
> In the case above, it's testing 5 things, so it's 5 lines. It's simple and
> therefore less error prone. Unit tests really should favor simplicity and
> correctness over reduced line count or increased cleverness. The goal of unit
> testing code is inherently different from normal code. _That_ is why unit testing
> code is written differently from normal code.

Thank you for your answer, Jonathan, makes much sense. Looks like the famous 
"who controls the controller" ;-) Your answer beeing "let us make the 
controller do its task in shuch a way that it does not require (much) control".

denis
-- 
_________________
vita es estrany
spir.wikidot.com