New submission from Julian Berman: 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. ---------- components: Library (Lib) messages: 169826 nosy: Julian, michael.foord priority: normal severity: normal status: open title: Use TestCase assertion methods in unittest.mock.assert* to make them easier to read versions: Python 3.3, Python 3.4 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15860> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
