replacing __dict__ with an OrderedDict
Roy Smith
roy at panix.com
Mon Jan 9 09:35:10 EST 2012
In article <mailman.4488.1325870461.27778.python-list at python.org>,
Ian Kelly <ian.g.kelly at gmail.com> wrote:
> Randomizing the order is not a bad idea, but you also need to be able
> to run the tests in a consistent order, from a specific random seed.
> In the real world, test conflicts and dependencies do happen, and if
> we observe a failure, make a change, rerun the tests and observe
> success, we need to be able to be sure that we actually fixed the bug,
> and that it didn't pass only because it was run in a different order.
I've seen this argument play out multiple times on this group.
Executive summary:
OP: "I want to do X"
Peanut Gallery: "You're not supposed to do that"
Here's my commentary on that.
The classic unittest philosophy says that tests should be independent of
each other, which means they should be able to be run in arbitrary
order. Some people advocate that the test framework should
intentionally randomize the order, to flush out inter-test dependencies
that the author didn't realize existed (or intend).
Test independence is a good thing. Many people don't understand this
when writing tests, and inadvertently write tests that depend on each
other. I've worked with those systems. They're a bear to debug.
You've got some test suite that runs for 15 minutes and dies at case 37
of 43. If you try to run case 37 by itself, it won't run, and you can't
figure out what state cases 1-36 were supposed to leave the system in to
make 37 work. You could sink days or weeks into debugging this kind of
crap. BTDT.
That being said, the unittest module, while designed to support the "all
tests must be independent" philosophy, is a useful piece of software for
lots of things. It provides an easy to use framework for writing tests,
lots of convenient assertions, reporting, test discovery, etc, etc.
If somebody (i.e. the classic "consenting adult" of the Python world)
wants to take advantage of that to write a test suite where the tests
*do* depend on each other, and have to be run in a certain order,
there's nothing wrong with that. As long as they understand the
consequences of their actions, don't try to preach unittest religion to
them. They're in the best position to know if what they're trying to do
is the best thing for their particular situation.
More information about the Python-list
mailing list