>> 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.
Then you're changing your story about the order. Which is fine, too. It
doesn't make the current order method less arbitrary.
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.
Let the developers decide for themselves which order is best. Imposing it
upon them is arbitrary. You may have a reason, but I don't agree with it, so
to me it makes no sense to be forced into alphabetic or random.
What if I have a bug that I find only when two tests are run one after the
other? What if I suspect this bug exists, and I can prove it exists by
running two tests one after the other? In celsoft.com/Battery, I can do that
easily. In Test/Unit, I can't do that (well, I can alias or just create
dummy methods, I assume, to get alphabetic...but that's not very Ruby-like).
> 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.
YOU said you ran the tests in Ruby order, not me. I only said "arbitrary."
That was the only word I used to describe your order. I didn't know it was
alphabetic, random or anything...they were just arbitrary to me. I couldn't
control the run order, so it imposed some order on me, and that's all I
remember about it. I said nothing about what specific order your tests ran
until someone said they were alphabetic, and then again when you said they
ran in the order Ruby listed them.
>> 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.
That is hypocritical. Let's just point that out. All this fuss because
people are upset that I don't like arbitrary run orders imposed on me, so I
wrote my own test framework and gave it to everyone. It's absolutely
hypocritical. The only thing you should be saying is "thanks for the ideas
and input Sean, and let the best test framework win." To get on board with
all these other jerks, just because of one word that I used properly and
because you want patches not competition...absolutely hypocritical. I never
did anything but go through a hell of a lot of trouble to write and release a
test framework that does things Test/Unit did.
> 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,
What I've learned is that this ML is filled with pseudo-intellectual children
who don't like when capable programmers demonstrate that they're not
dependent on their juvenile meanderings about what should and should not be
in the Ruby world, and can code what they need for themselves, and can get
their web pages in order and release something others can actually use, and
do so quickly, and in their spare time. So few of these whiners release much
of their own stuff, let alone get their documentation together. I can't
believe I take any stock in the blatherings of such ineffective, useless
play-coders.
Sean O'Dell
···
On Monday 14 June 2004 19:21, Nathaniel Talbott wrote:
On Jun 14, 2004, at 13:48, Sean O'Dell wrote:
> On Monday 14 June 2004 11:35, Mark Hubbart wrote:
