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