Robert Collins added the comment: The ordering is deliberate to support folk migrating from tearDown to cleanups - its not a bug. I thought we documented it clearly - https://docs.python.org/dev/library/unittest.html#unittest.TestCase.doCleanups - but if you wanted to submit improvements to the docs, that would be welcome.
The reverse ordering you propose, setup -> cleanups -> teardown means that its nearly impossible to migrate to cleanups bottom-up, you have to migrate top-down, which locks folk in inheritance based frameworks into waiting for the top of the tree to migrate first. class Base(TestCase): def setUp(self): super().setUp() self.helper = Something() def tearDown(self): self.helper.finished() self.helper = None super().tearDown() class Child(Base): def setUp(self): super().setUp() self.addCleanup(self.helper.release, my_resource) If the order is setup teardown cleanup then in the cleanup the helper is already finished, and the release call will fail. With the order of setup cleanup teardown The child's cleanup runs before the parents teardowns. It does of course pose the same reverse problem: the base of an inheritance based frame for tests needs to be more conservative adopting cleanups, or signal backwards incompatibility, but since that is generally true anyway (frameworks move slower than their users), we considered it a reasonable tradeoff. btw, you don't need a lambda in your example: self.addCleanup(print, 'destroying') ---------- nosy: +rbcollins _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24694> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
