Ordering tests in a testsuite

[Ben Finney]

Ulrich Eckhardt <eckhardt at satorlaser.com> writes:

> However, sometimes it doesn't make sense to run test_bar() if
> test_foo() already failed, because they basically build upon each
> other.

That's a mistake. If the success of ‘test_bar’ depends on the result of
‘test_foo’, then it's not an independent test and therefore isn't a unit
test.

Which is a good reason for re-ordering tests; it's even a good idea to
randomise the order in which they're run, but AFAIK the ‘unittest’
library doesn't do that yet.

If you have state needed by multiple tests, that's what the fixtures are
for: define a ‘setUp’ (and, if useful, ‘tearDown’) to handle common
fixtures needed by tests in the test class, and ensure they're in a
known state before each test.

-- 
 \         “Science is a way of trying not to fool yourself. The first |
  `\     principle is that you must not fool yourself, and you are the |
_o__)               easiest person to fool.” —Richard P. Feynman, 1964 |
Ben Finney