On Feb 11, 2011, at 12:24 AM, Jonathan M Davis <[email protected]>
wrote:
On Thursday, February 10, 2011 14:28:22 Andrei Alexandrescu wrote:
On 2/10/11 11:33 AM, Jonathan M Davis wrote:
Well, as Steven says, most of std.datetime is unit tests. And
probably
over half of the rest is documentation, since most of the functions
themselves are relatively short and simple.
That means there are too many unit tests. There is such a thing as
too
much of a good thing.
Add to that that I tend to like a fair bit of
vertical space in my code (e.g. return statements pretty much
always
have a blank line above them), and how I code tends to take up a
fair
bit more LOC than you would without actually being more code.
As I mentioned, it would be courteous to your other colleagues if you
were more economical with vertical space. Many people (and most of
Phobos devs) consider vertical space a rare commodity.
It wouldn't surprise me that if I
were to format std.algorithm in a manner that I'd typicall write
it, it
would at least double in line count simply due to additional blank
lines
that I'd introduce for code legibility.
I consider legible code compact code that I can keep on one screen
and
understand what it does.
There aren't very many functions in std.datetime which wouldn't fit
one one
screen. Regardless, it's obvious that code legibility is a
subjective thing.
And, of course, if I'd written std.algorithm, it
would almost certainly have had quite a few more unit tests. None
of that
increases the size of the actual binary.
It's not the size of the binary I'm worried about.
I don't think that std.datetime is the
largest module in Phobos, but I do think that comparing its line
count to
something like std.algorithm really tells you how much of a
difference it
makes in the size of the binary - especially when so much of it is
unit
tests which wouldn't end up in a binary.
One thing is certain: someone who wants to take a look at
std.datetime
has the prospect of navigating 34KLOC.
The unit testing functions I wrote are pretty much in the same
boat. They
had thorough unit tests - testing not only all of its code paths
(which
is what the % code coverage gives you) but an appropriate range of
values. The functions themselves weren't all that long.
They are unrolled loops that should be rolled. Most likely they
test the
same thing several times.
Some of them could be easily turned into loops - others not (most
probably not).
There was not ONE I looked at that couldn't be reduced by using a loop.
They don't generally quite test a set of consecutive values, though
there is
often a pattern to them.
They apply the same call to different values and check results. Loop.
I tend to dislike doing much complicated just to try
and reduce the lines in a unit test, because the risk of screwing it
up goes up,
and if the tests are wrong, the code will be wrong. So, the tests
are simple but
repetitive.
I don't buy this argument at all. What, are simple loops difficult all
of a sudden? Then, one should strive to make all code simple; the
argument is not for unittests only. The unittest scope is not a
license to throw all good practices out the window and write bloat.
The risk of screwing up like that for std.datetime is lower at this
point, since
it has already been thoroughly tested (the likelihood of a test
failure when
changing the tests is now much more likely to be a screwed up test
rather than
the code being broken). So, I'd be far more willing to try to alter
the tests to
take up less space now that I would have been when writing it.
Not buying this any more than the other. Good unittests are as goo as
bulky unittests - in fact way better.
I suppose that I could look at trying to turn some of the tests into
arrays
which get looped over. That sort of thing is not always going to be
possible
though, regardless of how repetitive the tests may seem.
I'd be hard pressed to find unittests tha are not, in fact, loops.
And while the functions
aren't generally long, and _most_ of them are simple, there _are_
some of them
with calculations which are easy to screw up, and a lot of tests are
necessary
to catch edge cases and the like. For instance, at one point, I
thought that I'd
finally gotten the gregorian day calculations right only to find
that when I added
tests for negative years which ended in 99, the result was always 1
day off. I
only caught it because I had a lot of tests.
Loops would have caught those too.
While I'm fine with the tests as they are, obviously others aren't.
So, I'll see
if I can reasonably reduce how many lines they take up. But I'm not
particularly
willing to reduce what's being tested.
Jonathan, you are definitely right in principle. It's just the
frightening proportions you are taking this to. Unittests are great.
10x unittests are not. I feel we cannot count here on some simple
commonsense limits that would normally need no debate.
Andrei
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
