Hello all, I would like to propose refactoring the assertions out of unittest.TestCase. As code speaks louder than words, you can see my initial work at https://github.com/OddBloke/cpython. The aim of the refactor is: (a) to reduce the amount of repeated code in the assertions, (b) to provide a clearer framework for third-party assertions to follow, and (c) to make it easier to split gnarly assertions in to an easier-to-digest form. My proposed implementation (as seen in the code above) is to move each assertion in to its own class. There will be a shared superclass (called Assert currently; see [0]) implementing the template pattern (look at __call__ on line 69), meaning that each assertion only has to concern itself with its unique aspects: what makes it fail, and how that specific failure should be presented. To maintain the current TestCase interface (all of the tests pass in my branch), the existing assert* methods instantiate the Assert sub-classes on each call with a context that captures self.longMessage, self.failureException, self.maxDiff, and self._diffThreshold from the TestCase instance. Other potential aims include eventually deprecating the assertion methods, providing a framework for custom assertions to hook in to, and providing assertion functions (a la nose.tools) with a default context set. This proposal would help address #18054[1] as the new assertions could just be implemented as separate classes (and not included in the TestCase.assert* API); people who wanted to use them could just instantiate them themselves. I’d love some feedback on this proposal (and the implementation thus far). Cheers, Dan (Odd_Bloke) [0] https://github.com/OddBloke/cpython/blob/master/Lib/unittest/assertions/__in... [1] http://bugs.python.org/issue18054
Have you seen Matchers? Inspired by hamcrest, these also move assertions out of unittest.TestCase, but are much more composable than assertions, and can give significantly richer errors. http://testtools.readthedocs.org/en/latest/for-test-authors.html#matchers There is an open ticket in the Python bug tracker for getting something like this into the stdlib. I've been meaning to port them and get a review up for a bit :(. -Rob On 30 November 2013 22:26, Daniel Watkins <daniel@daniel-watkins.co.uk> wrote:
Hello all,
I would like to propose refactoring the assertions out of unittest.TestCase. As code speaks louder than words, you can see my initial work at https://github.com/OddBloke/cpython.
The aim of the refactor is: (a) to reduce the amount of repeated code in the assertions, (b) to provide a clearer framework for third-party assertions to follow, and (c) to make it easier to split gnarly assertions in to an easier-to-digest form.
My proposed implementation (as seen in the code above) is to move each assertion in to its own class. There will be a shared superclass (called Assert currently; see [0]) implementing the template pattern (look at __call__ on line 69), meaning that each assertion only has to concern itself with its unique aspects: what makes it fail, and how that specific failure should be presented.
To maintain the current TestCase interface (all of the tests pass in my branch), the existing assert* methods instantiate the Assert sub-classes on each call with a context that captures self.longMessage, self.failureException, self.maxDiff, and self._diffThreshold from the TestCase instance.
Other potential aims include eventually deprecating the assertion methods, providing a framework for custom assertions to hook in to, and providing assertion functions (a la nose.tools) with a default context set.
This proposal would help address #18054[1] as the new assertions could just be implemented as separate classes (and not included in the TestCase.assert* API); people who wanted to use them could just instantiate them themselves.
I’d love some feedback on this proposal (and the implementation thus far).
Cheers,
Dan (Odd_Bloke)
[0] https://github.com/OddBloke/cpython/blob/master/Lib/unittest/assertions/__in...
[1] http://bugs.python.org/issue18054
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas
-- Robert Collins <rbtcollins@hp.com> Distinguished Technologist HP Converged Cloud
Hi Rob, On Sat, Nov 30, 2013 at 10:38:31PM +1300, Robert Collins wrote:
Have you seen Matchers? Inspired by hamcrest, these also move assertions out of unittest.TestCase, but are much more composable than assertions, and can give significantly richer errors.
http://testtools.readthedocs.org/en/latest/for-test-authors.html#matchers
I hadn't given it a proper look. Very cool! This looks like a much more adaptable solution than mine.
There is an open ticket in the Python bug tracker for getting something like this into the stdlib. I've been meaning to port them and get a review up for a bit :(.
Great! Two things that (at a glance) testtools is missing are diffs to describe mis-matches and support for the existing attributes (longMessage, maxDiff, failureException, _diffThreshold) that unittest.TestCase uses to manage output (though, obviously, at least two of these are diff-related). Are there any thoughts as to how to address this? Is there anything I can do to help push matchers in to the stdlib? Cheers, Dan
Hi, Nice ! Maybe lib operator can help you. I've opened a ticket few days ago on this topic: http://bugs.python.org/issue19645 I'm working on, making some tests, to have a POC for a possible PEP. Actually I've kept these ideas: - independant from unittest - same behaviour as "assert" in optimize mode (trying to see if it would be convenient to have an env var to force it) - simple matchers compatibles with testtools protocol - factories to make assertions Idea I've to dig further: provide a mecanism to override "assert" (thought for py.test) If you're interested we can work together. 2013/11/30 Robert Collins <robertc@robertcollins.net>
Have you seen Matchers? Inspired by hamcrest, these also move assertions out of unittest.TestCase, but are much more composable than assertions, and can give significantly richer errors.
http://testtools.readthedocs.org/en/latest/for-test-authors.html#matchers
There is an open ticket in the Python bug tracker for getting something like this into the stdlib. I've been meaning to port them and get a review up for a bit :(.
-Rob
On 30 November 2013 22:26, Daniel Watkins <daniel@daniel-watkins.co.uk> wrote:
Hello all,
I would like to propose refactoring the assertions out of unittest.TestCase. As code speaks louder than words, you can see my initial work at https://github.com/OddBloke/cpython.
The aim of the refactor is: (a) to reduce the amount of repeated code in the assertions, (b) to provide a clearer framework for third-party assertions to follow, and (c) to make it easier to split gnarly assertions in to an easier-to-digest form.
My proposed implementation (as seen in the code above) is to move each assertion in to its own class. There will be a shared superclass (called Assert currently; see [0]) implementing the template pattern (look at __call__ on line 69), meaning that each assertion only has to concern itself with its unique aspects: what makes it fail, and how that specific failure should be presented.
To maintain the current TestCase interface (all of the tests pass in my branch), the existing assert* methods instantiate the Assert sub-classes on each call with a context that captures self.longMessage, self.failureException, self.maxDiff, and self._diffThreshold from the TestCase instance.
Other potential aims include eventually deprecating the assertion methods, providing a framework for custom assertions to hook in to, and providing assertion functions (a la nose.tools) with a default context set.
This proposal would help address #18054[1] as the new assertions could just be implemented as separate classes (and not included in the TestCase.assert* API); people who wanted to use them could just instantiate them themselves.
I’d love some feedback on this proposal (and the implementation thus far).
Cheers,
Dan (Odd_Bloke)
[0] https://github.com/OddBloke/cpython/blob/master/Lib/unittest/assertions/__in...
[1] http://bugs.python.org/issue18054
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas
-- Robert Collins <rbtcollins@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas
participants (3)
-
Daniel Watkins -
Gregory Salvan -
Robert Collins