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')