[phobos] Split std.datetime in two?

[Jonathan M Davis]

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.

- Jonathan M Davis