Ordering tests in a testsuite

Steven D'Aprano steve at REMOVE-THIS-cybersource.com.au
Fri Oct 8 02:42:34 CEST 2010

On Fri, 08 Oct 2010 08:35:12 +1100, Ben Finney wrote:

> 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.

I don't think that is what Ulrich means to imply. I don't think he means 
that test_bar uses the result of test_foo, but only that if test_foo 
fails then test_bar has no hope of succeeding.

To give an example, suppose you have:

class MyClass:
    def __init__(self, cheese):
        self.cheese = cheese

class MyTests(unittest.TestCase):
    def test_create(self):
        # Test that instances can be created correctly.
        self.assert_raises(TypeError, MyClass)
        x = MyClass("cheddar")  # will fail if MyClass can't be created
    def test_cheese(self):
        # Test that instances have a cheese attribute.
        x = MyClass("swiss")
        self.assertEquals(x.cheese, "swiss")

If test_create fails, then so will test_cheese, not because the later 
test is dependent on the first, but because creation is more fundamental 
than attribute access. I think the OP wants to skip test_cheese in the 
even that test_create fails.


More information about the Python-list mailing list