[issue19645] decouple unittest assertions from the TestCase class

Robert Collins added the comment: Oh, I didn't mean to imply that these are the only options I'd support - just that these are the things I've thought through and that I think will all work well... I'm sure there are more options available ;) --

[issue19645] decouple unittest assertions from the TestCase class

Change by Robert Collins : -- versions: +Python 3.9 -Python 3.5 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue19645] decouple unittest assertions from the TestCase class

Robert Collins added the comment: Ok so design wise - there is state on the TestCase that influences assertions; in potentially two ways. The first way is formatting - the amount of detail shown in long list comparisons etc. The second way I don't think we have at the moment, but

[issue19645] decouple unittest assertions from the TestCase class

R. David Murray added the comment: "But - what are we solving for here?" I'll tell you what my fairly common use case is. Suppose I have some test infrastructure code, and I want to make some assertions in it. What I invariably end up doing is passing 'self' into the infrastructure

[issue19645] decouple unittest assertions from the TestCase class

Pascal Chambon added the comment: "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

[issue19645] decouple unittest assertions from the TestCase class

Robert Collins added the comment: Right now that attribute could be set by each test separately, or even varied within a test. TBH I'm not sure that the attribute really should be supported; perhaps thinking about breaking the API is worth doing. But - what are we solving for here. The OP

[issue19645] decouple unittest assertions from the TestCase class

Michael Foord added the comment: Or even making the assert methods into custom descriptors. -- ___ Python tracker ___ ___

[issue19645] decouple unittest assertions from the TestCase class

Michael Foord added the comment: Hmm, it could be done by __init_subclass__ potentially. -- ___ Python tracker ___ ___

[issue19645] decouple unittest assertions from the TestCase class

Michael Foord added the comment: Suppose failureException is set to TypeError on that TestCase class, how would your assertEquals signal failure to the test runner? -- ___ Python tracker

[issue19645] decouple unittest assertions from the TestCase class

Pascal Chambon added the comment: I don't get it, why would failureException block anything ? The unittest.TestCase API must remain the same anyway, but it could become just a wrapper towards external assertions. For example : class TestCase: assertEqual = wrap(assertions.assert_equal)

[issue19645] decouple unittest assertions from the TestCase class

Michael Foord added the comment: Has anyone seen any real world use cases for failureException? It's a real hindrance to a whole bunch of changes sounds decoupling. On the other hand something like assertThat could catch a custom exception from the matchers (subclass of AssertionError) and

[issue19645] decouple unittest assertions from the TestCase class

Pascal Chambon added the comment: (Redirected here from https://bugs.python.org/issue37262) I haven't dug the assertThat() idea, but why not make, as a first step, turn assertion methods in TestCase to staticmethods/classmethods, instead of instance methods? Since they (to my knowledge)

[issue19645] decouple unittest assertions from the TestCase class

Robert Collins added the comment: Sorry for the slow reply here; There are API breaks involved in any decoupling that involves the exception raising because of the failureException attribute. Something with signalling that can be adapted by other test suites etc might have merit, but I

[issue19645] decouple unittest assertions from the TestCase class

Robert Collins added the comment: Hi, I'm glad you're interested in this. I very much want to see a matcher/hamcrest approach rather than a library of assertions per se - because match-or-except makes layering things harder. -- ___ Python tracker

[issue19645] decouple unittest assertions from the TestCase class

Serhiy Storchaka added the comment: Here are most popular idioms which deserve special assertion methods: assertHasAttr(obj, name) == assertTrue(hasattr(obj, name)) assertIsSubclass(type, expected) == assertTrue(issubclass(type, expected)) assertTypeIs(obj, expected) == assertIs(type(obj),

[issue19645] decouple unittest assertions from the TestCase class

Changes by Martin Panter vadmium...@gmail.com: -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19645 ___ ___ Python-bugs-list

[issue19645] decouple unittest assertions from the TestCase class

Changes by Julian Berman julian+python@grayvines.com: -- nosy: +Julian ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19645 ___ ___

[issue19645] decouple unittest assertions from the TestCase class

Changes by Éric Araujo mer...@netwok.org: -- nosy: +eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19645 ___ ___ Python-bugs-list

[issue19645] decouple unittest assertions from the TestCase class

Gregory Salvan added the comment: issue18054 : - adding assertCleanError in the ipaddress module, - suggesting assertCleanTraceback, assertRaisedFrom in unittest - usefull but TestCase has already a wide api. A solution like Testtools assertThat with matcher protocol

[issue19645] decouple unittest assertions from the TestCase class

R. David Murray added the comment: You should probably start by summarizing the assertThat proposal from issue 18054, which suggested making a separate issue for assertThat. -- nosy: +r.david.murray title: Improving unittest assertions - decouple unittest assertions from the TestCase