[TIP] RFC: Post-assertRaises assertions WAS: ANN: unittest2 0.4.0 Release
fuzzyman at voidspace.org.uk
Fri Apr 9 09:27:58 PDT 2010
On 09/04/2010 14:55, Olemis Lang wrote:
> On Fri, Apr 9, 2010 at 8:15 AM, Michael Foord<fuzzyman at voidspace.org.uk> wrote:
>> On 09/04/2010 14:10, Olemis Lang wrote:
>>> On Thu, Apr 8, 2010 at 5:42 PM, Michael Foord<michael at voidspace.org.uk>
>>>> Hello all,
>>>> I'm pleased to announce the release of version 0.4.0 of unittest2.
>>>> For full details of all the new features, see my blog entry:
>>> I wanted to know if you have considered support for writing assertions
>>> targeting the exception object been raised . In my experience that is
>>> very helpful when testing some kind of systems. For instance, in Trac
>>> XmlRpcPlugin (<=0.1.6, current trunk ;o) you can find many tests
>>> (actually all TCs checking for error conditions ;o) like this
>> Did you check the docs?
> Good RTFM , thnx . Should be something like this (isn't it ?):
> # blah blah blah ...
> def test_wrong_argspec(self):
> ctx = self.assertRaises(xmlrpclib.Fault)
> with ctx :
> self.fail("Oops. Wrong argspec accepted???")
> e = ctx.exception
> self.assertEquals(1, e.faultCode)
> self.assertTrue("listMethods() takes exactly 2 arguments" \
> in e.faultString)
> However I'm also interested in how it works (backwards compatibility
> ;o) for versions with no support for context managers (AFAIK, there
> are still people using Trac on Py 2.4 ;o)
> Is it possible to consider returning the exception object when the
> ctxman is not returned ?
No, sorry. There is no need for this in Python 2.7 (which has context
managers) and I'm not going to put incompatible changes into unittest2.
You can still use the alternative version of assertRaises if you *just*
want to check the exception message.
> Thnx for the pointer
> PS: I read the comment about Guido's msg and I really don't agree with
> «I can see how it's sometimes more powerful, but I'd say that in many
> cases assertRaisesWithMessage will be easier to write and read.»
> mainly because in the concrete use case I mentioned before that
> approach is definitely worthless since we need to check other attrs
> not just exception message, and we would need to override
> `assertRaises` anyway (i.e. I see no reason for not using the more
> generic approach )
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
More information about the testing-in-python