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.)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

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

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 <jmdavisProg at gmx.com> 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
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

On 02/11/2011 06:02 PM, Andrei Alexandrescu wrote:
> 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.

Right. But then, on failure, one needs to edit the testing loop to make it
output needed piece(s) of information just to know what/how/why about actual
test failure case. This, because we're missing a feature.
Or (as I do as a workaround), build your test funcs with that
information-providing statement(s), which is highly helpful (for me at least)
during development phase. Then when all works fine, comment them out. On
failure, just uncomment, and you'll get back all relevant info; even better,
you'll get them under the same form as before (which possibly has been refined
during develoment).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com