I’ll tell you what, though, I will concede that that the cost of not depending on test ordering is just a few lines of code. I’ll also agree that that cost is small enough that allowing for random order/individual running is more of a win than the cost.

This does raise an interesting question… has anyone released a nose plugin that does random test ordering?

Anecdote: I once found a bug in my Cartwheel project (probably my biggest public project) that I detected because I could run tests in any order. The bug was severe but basically invisible; I don’t think I would have found it any other way until it had caused data corruption in my database.

More generally, order dependency of tests allows hidden linkages between disparate parts of your program. These are sources of additional complexity and (therefore) often sources of bugs…

but I’ll stop brow-beating you now

@Titus: I generally don’t care about running individual test cases. Any single test module of mine runs quickly enough that it’s not a problem.

And, it only takes a few seconds to communicate to others on my team that the test cases are set up to run in order. (For a public project, there is a difference there…)

I actually don’t tend to run into many bugs that would be caught by reordering my tests…

That said, when I switched to py.test/nose/testido (the thing I made before nose came into existence), I stopped using unittest.TestCases because of how annoying they were to work with. The reason that unittest.TestCases are annoying is really only test collection, though. You’re right that unittest.TestCases are plenty convenient when working within nose, and I will consider using them the next time I have more fixture I want to build up and tear down.

Just because I don’t have to use unittest.TestCase doesn’t mean I shouldn’t

Some reasons why:

- you can’t run individual test cases reliably if they depend on other tests to do the correct thing

- setup and teardown are what the setup and teardown fixtures are FOR

- you’re violating commonly held expectations of unittest - for better or for worse, people EXPECT test cases to be independent

- running tests in random order is a great way to find hidden dependencies in the code you are testing. Such hidden dependencies are a major source of bugs, in my experience.

The real question is this, tho: to re-use test fixtures, why not have the appropriate setup/teardown functions attached to a class, and group the tests by classes? (There are plenty of other options in both nose and py.test for doing this, but I tend to just use classes.)