Robert Collins added the comment: Setting some basic design parameters here.
Its ok for a test to know if it itself has decided on some status. See e.g. testtools.expectThat for a related design thing. Making some official API within the test itself so code after the failure can take appropriate actions seems pretty safe to me, as long as its a one-way switch - no backsies. I think inspecting the reporter would be overly limiting on the reporter implementation, and we shouldn't do that. Further, I think limiting the possible status's that we track to the minimum would be good here, even though its inconsistent with the current overly rich separation unittest offers. That is, some self.status field which might even be an enum (if enum34 supports Python 2.6 for backports [as unittest is currently backported to 2.6 and up]. unset success unexpected success skipped failed expected failure ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24249> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
