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

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 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 Distinguished Technologist HP Converged Cloud _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas