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 Julian
Recipients Julian, michael.foord
Date 2012-09-04.13:06:58
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1346764020.36.0.830519299083.issue15860@psf.upfronthosting.co.za>
In-reply-to
Content
Mock's assertion failures can be extremely hard to read for a few reasons -- mostly the noisy default repr that mock objects have, but also because they don't give you the hints that `unittest.TestCase`'s `assert*` methods give you (things like diffing two lists for example).

unittest.mock.Mock's `assert*` methods could hook into the TestCase's assertion methods if Mock either gained a MockInTestCase subclass or started taking an arg to `__init__` that was an instance of `TestCase`, so that `assert*` could then use the assertion methods on the instance.

#11664 could (should) then obviously use this argument by default when patching.

Another added advantage would be that the raised exception could then be `TestCase.failureException`, whatever that might be, rather than `AssertionError`, though I doubt that's that big a deal since that's usually a subclass of `AssertionError` I bet.
History
Date User Action Args
2012-09-04 13:07:00Juliansetrecipients: + Julian, michael.foord
2012-09-04 13:07:00Juliansetmessageid: <1346764020.36.0.830519299083.issue15860@psf.upfronthosting.co.za>
2012-09-04 13:06:59Julianlinkissue15860 messages
2012-09-04 13:06:58Juliancreate