[phobos] Split std.datetime in two?

[Andrei Alexandrescu]

Again, in principle this is violent agreement. Many unittests?  
Love'em. Simple unittests? Keep'em that way. But when I look at  
std.datetime, I can clearly see that these good principles can be  
taken to scales that just are out of proportion.

Btw to be clear: I consider code organized around loops comparing  
inputs with expected outputs simpler. For one thing I can see more of  
it, and it's obvious that only one function is tested. Then it's  
easier to maintain too. I consider the long copied invocations with  
one parameter varying indefensible in any circumstance, and I feel a  
mix of desperation and resignation that I need to debate this.

Sent by shouting through my showerhead.

On Feb 11, 2011, at 11:32 AM, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> On Friday 11 February 2011 02:24:08 spir wrote:
>> On 02/11/2011 10:18 AM, Jonathan M Davis wrote:
>>> However, I do acknoweldge that most people here disagree with me and
>>> think that the length of the unit tests in std.datetime is  
>>> excessive and
>>> problematic. So, I will take time sometime relatively soon and  
>>> work on
>>> making them take less space. And any future anything that I  
>>> propose to
>>> Phobos, I will work on minimizing the amount of space that its unit
>>> tests take up before I propose it.
>>
>> Why not just do this as a final refactoring of each unitest, once  
>> all runs
>> fine? (At least, if your tests are commonly suites of the same  
>> pattern
>> with various input (mine are rarely like that, rather simulating  
>> client
>> process using tested functinality), then use case arrays, I guess.)
>
> Well, that's essentially what I'll be doing in the case of  
> std.datetime, since
> it's already been written, tested, and debugged with the tests as  
> they are. It's
> probably what I'll do with future code as well.
>
> I really do think that unit tests should strive to be dead simple so  
> that
> there's a lower risk of the tests being wrong. Once the  
> functionality is
> complete, and you're reasonably certain that it's correct, then when  
> you alter
> the tests to be less verbose, you at least have the confidence that  
> when the
> tests fail, it's the tests that are wrong rather than the code. If  
> the code is
> new however, that's a lot less clear. And the more complicated the  
> tests, the
> more likely that they're wrong and the more likely that you'll miss  
> bugs.
>
> - Jonathan m Davis
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos