On Feb 11, 2011, at 12:34 AM, Jonathan M Davis <[email protected]>
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.
Not taking one femtosecond to believe that. The hard part is to get
the unittest to fail. Once it fails, it is all trivial. Insert a
writeln or use a debugger.
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.
I am now having a major burden finding the code that does work in a
sea of chaff.
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.
All code should do that. This is a false choice. Good code must go
inside unittest and outside unittest.
The goal of unit
testing code is inherently different from normal code. _That_ is why
unit testing
code is written differently from normal code.
Not buying it. Unittest code is not exempt from simple good coding
principles such as avoiding copy and paste.
Andrei
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
