On Jun 14, 2004, at 13:48, Sean O'Dell wrote:

> On Monday 14 June 2004 11:35, Mark Hubbart wrote:
>
>> But it remains that you called the alphabetical ordering (and the
>> decision to use it) arbitrary. Arbitrariness, by definition, requires
>> either randomness or capriciousness. I think this is not supported by
>> evidence. as for the ordering itself being either random or 
>> capricious,
>> well, that's silly. It may not be the ordering you expect, but it
>> *certainly* isn't random. As for the decision: If it were my software
>> library, I would feel insulted were someone to call my decision
>> capricious, if I had put some time into working it out. And telling
>> someone that their decision was random, when it involves a project 
>> that
>> they built, and they probably care about deeply and are proud of, 
>> seems
>> very rude. Calling the ordering arbitrary was okay, since you didn't
>> know better at the time; but calling his *decision* arbitrary was
>> uncalled for.
>
> That's not the precise meaning of the word, but Nathaniel did admit to 
> it, and
> I never meant to insult Nathaniel.

Thanks for not trying to insult me, Sean, but please quote me in full...

I wrote:

> Early in test/unit's life, test order was arbitrary (well, OK, they 
> were actually run in the order that Module#public_instance_methods 
> returned them... but that was pretty arbitrary). In general, this was 
> not a bad thing, because unit tests that are dependent on test order 
> are a pretty serious code smell. However, PragDave pointed out that 
> adding a bit more predictability would be a good thing, so I started 
> sorting the methods alphabetically. This allows one to order test 
> methods via naming 'hacks', but they feel like hacks. Some people 
> don't like that, but I consider it to be a feature, because THEY ARE 
> hacks.
>
> So yes, I can agree that sorting alphabetically is a fairly arbitrary 
> decision (although I can't think of another order I would prefer in 
> its place). However, the choice to not make ordering an important part 
> of test/unit's function is not arbitrary. The only other ordering I 
> have really considered adding random order, with the seed being 
> printed out each run so that results can be duplicated. That would be 
> useful for removing inter-test dependencies, while most other 
> orderings I can think of would encourage them.

To clarify, since apparently I wasn't clear enough originally:

   1) The current ordering of tests (alphabetical) could be considered 
arbitrary, as I could have arguably chosen something better. However, I 
personally can't think of another, better ordering the framework could 
provide.

   2) As Mark put it so well above, the decision to only provide 
alphabetical ordering WAS NOT arbitrary. I did it to make it feel like 
a hack because every single unit testing reference I have ever read and 
my own experience tell me that order-dependent tests are not a good 
thing.


> I removed the word from all docs the very
> second someone mentioned that it appeared insulting.  Also, I never 
> directly
> applied the word "arbitrary" to Test/Unit; people just made the 
> association
> themselves because, well, Test/Unit really did run tests according to 
> how
> Ruby listed them, which seemed random to me, but I'm not sure; I 
> couldn't
> find a pattern to them.

Actually, I just looked, and it turns out test/unit has never run tests 
in "Ruby order" - only Lapidary did. Alphabetical sorting was added in 
October of 2001, so unless you were using Lapidary in 2001, this is 
simply an inaccurate statement.


>> Having the option to order tests is good. Having multiple output
>> formats is good. I suspect that both of those will end up being
>> absorbed by the Test::Unit framework, and your project will have done
>> it's job, contributing to the quality and flexibility of Ruby's
>> libraries. If they aren't added, I suspect you will flesh out your
>> framework to be as feature-rich as the official one. And that will be
>> good too. :)
>
> I'll be on it, that's for sure.  I got sick, a long time ago, of 
> asking for
> things and getting a lot of heat for it so these days, when possible, 
> I will
> just implement what I need myself and if I have time, release it 
> publicly.

As has been mentioned here several times, offering patches or add-on 
components is a middle ground between simply asking for functionality, 
and re-implementing a completely new library almost identical to one 
that is already available. I feel somewhat like a hypocrite saying 
this, as I did the latter with test/unit, replacing RubyUnit, which was 
the generally used framework at the time. So simply take it as a 
suggestion - that's all it is. I do think your alternative output 
format could have easily been implemented as a new test/unit runner.


> Diplomacy
> is tough to have when you simply don't have the room to compromise on 
> some
> things.

Also: Learning is tough to have when you simply don't have the room to 
be wrong on some things.

May we all give ourselves room to learn,


Nathaniel
Terralien, Inc.

<:((><