Ulrich Eckhardt <eckha...@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 -- http://mail.python.org/mailman/listinfo/python-list