Ordering tests in a testsuite
Steven D'Aprano
steve at REMOVE-THIS-cybersource.com.au
Thu Oct 7 20:42:34 EDT 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.
--
Steven
More information about the Python-list
mailing list