E.g.:
class Outer(Spec):
def setup(self):
print "foo"
def a_test(self):
assert True
class inner:
def another_test(self):
assert True
Running this file will see setup() run 2x during execution of inner.another_test.
This is problematic when e.g. performing additive state changes within setup, such as calls to mock.patch/mock.patch.start, which add to an internal-on-their-end data structure. Thus, using teardown() to "undo" things done this way in setup() will not suffice as it only undoes the outermost copy of the action.
The problem code is in the __getattr__ wrapper used when decorating the inner classes, which "conveniently" calls setup() on an instance of the outer class. IIRC this was done so that accessing self.parent ran the parent's setup(), otherwise, e.g. self.parent.an_attr_set_during-setup would not exist).
It's unclear why this is leading to 2x calls of the same setup, unless the inner class is also inheriting the setup code somehow (AFAIK this is not the case or we wouldn't even have that silly wrapper.)
E.g.:
Running this file will see
setup()run 2x during execution ofinner.another_test.This is problematic when e.g. performing additive state changes within
setup, such as calls tomock.patch/mock.patch.start, which add to an internal-on-their-end data structure. Thus, usingteardown()to "undo" things done this way insetup() will not suffice as it only undoes the outermost copy of the action.The problem code is in the
__getattr__wrapper used when decorating the inner classes, which "conveniently" callssetup()on an instance of the outer class. IIRC this was done so that accessingself.parentran the parent'ssetup(), otherwise, e.g.self.parent.an_attr_set_during-setupwould not exist).It's unclear why this is leading to 2x calls of the same setup, unless the inner class is also inheriting the setup code somehow (AFAIK this is not the case or we wouldn't even have that silly wrapper.)