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