Minitest was intended to be a minimal replacement for Test::Unit and =
RSpec. It mostly succeeds in this goal; however, it violates it in one =
annoying case. It adds a feature not found in RSpec, a feature that I =
find noble in theory, but troublesome in practice: test randomization. =
And it enables it by default.

This has no practical effect on an all-succeeding suite, or one in which =
a single test is failing. But if you have a few failing tests, it =
completely messes with your mind. Usually you will focus in on a single =
failing test and work to make that one pass; usually this is the first =
one to fail. But the randomization means that when you run it and watch =
it fail again you have to squint and read through all the randomly =
ordered failures to see where your current victim is. It's a real flow =
killer.

Randomization also mandates spewing options (notably seed) onto the =
console, which serve only to clutter up the display and obscure the =
all-important success or failure methods. And for some reason you're =
printing them twice (once at the beginning and again at the end of the =
run). And even if knowing the seed is important if it provoked a =
failure, why bother printing them during a successful run?

Moreover, most well-factored OO code these days does not exhibit =
isolation problems. Yes, it's a good idea to randomize your tests once =
in a while -- say, once before checking in, or before a release -- but =
the benefit is not worth the above costs. And even if I thought it were =
worth it, an alleged functional replacement library should not go =
changing default behavior like that.

If I submit a patch to do the following, will you accept it?

* make test randomization an option ("randomize")
* make the default for that option be "off"
* output the command-line options only if one of the following is true:
** "verbose" is on
** "randomize" is on AND there was a failure

Cheers -

 - Alex (the Wrong guy :-))