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
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
