This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pakal
Recipients Gregory.Salvan, Julian, eric.araujo, martin.panter, michael.foord, ncoghlan, pakal, r.david.murray, rbcollins, serhiy.storchaka
Date 2019-06-13.11:43:48
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1560426228.2.0.645981972677.issue19645@roundup.psfhosted.org>
In-reply-to
Content
"Suppose failureException is set to TypeError on that TestCase class, how would your assertEquals signal failure to the test runner?"

failureException is an artefact from unittest.TestCase. It's only supposed to be used in a TestCase context, with an unittest-compatible runner. If people corrupt it, I guess it's their problem?

The point of decoupling is imho that other test runner might use the separate set of assertions. These assertions should raise a sensible default (i.e AssertionError) when encountering troubles, and accepting an alternate class as parameter will allow each test framework to customize the way these assertions behave for it.
History
Date User Action Args
2019-06-13 11:43:48pakalsetrecipients: + pakal, ncoghlan, rbcollins, eric.araujo, r.david.murray, michael.foord, Julian, martin.panter, serhiy.storchaka, Gregory.Salvan
2019-06-13 11:43:48pakalsetmessageid: <1560426228.2.0.645981972677.issue19645@roundup.psfhosted.org>
2019-06-13 11:43:48pakallinkissue19645 messages
2019-06-13 11:43:48pakalcreate