[Python-ideas] Refactor Assertions Out of unittest.TestCase

[Gregory Salvan]

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 at 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 at 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/__init__.py#L15
> >
> > [1] http://bugs.python.org/issue18054
> >
> > _______________________________________________
> > Python-ideas mailing list
> > Python-ideas at python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> >
>
>
>
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20131130/2f7def92/attachment.html>