Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #22275

unittest: assertRaises() with an instance instead of a type

From Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com>
Newsgroups comp.lang.python
Subject unittest: assertRaises() with an instance instead of a type
Date 2012-03-28 14:28 +0200
Message-ID <pncb49-ur7.ln1@satorlaser.homedns.org> (permalink)

Show all headers | View raw


Hi!

I'm currently writing some tests for the error handling of some code. In 
this scenario, I must make sure that both the correct exception is 
raised and that the contained error code is correct:


   try:
       foo()
       self.fail('exception not raised')
   catch MyException as e:
       self.assertEqual(e.errorcode, SOME_FOO_ERROR)
   catch Exception:
       self.fail('unexpected exception raised')


This is tedious to write and read. The docs mention this alternative:


    with self.assertRaises(MyException) as cm:
        foo()
    self.assertEqual(cm.the_exception.errorcode, SOME_FOO_ERROR)


This is shorter, but I think there's an alternative syntax possible that 
would be even better:


     with self.assertRaises(MyException(SOME_FOO_ERROR)):
         foo()


Here, assertRaises() is not called with an exception type but with an 
exception instance. I'd implement it something like this:


     def assertRaises(self, exception, ...):
         # divide input parameter into type and instance
         if isinstance(exception, Exception):
             exception_type = type(exception)
         else:
             exception_type = exception
             exception = None
         # call testee and verify results
         try:
             ...call function here...
         except exception_type as e:
             if not exception is None:
                 self.assertEqual(e, exception)


This of course requires the exception to be equality-comparable.


Questions here:
1. Does this sound like a useful extension or am I missing another 
obvious solution to my problem?
2. The assertRaises() sketch above tries to auto-detect whether the 
given parameter is the type or an instance. Given the highly dynamic 
nature of Python, an object can be both instance and type, is the above 
detection mechanism reliable?


Of course I'm open for other suggestions to solve my problem. One that I 
thought of but which I haven't really looked into was to modify __init__ 
or __new__ of my exception class to return an instance of a derived 
class that uniquely identifies the error. I.e. 
MyException(SOME_FOO_ERROR) would not create a MyException instance but 
a MyFooErrorException instance (which has MyException as a baseclass). 
In that case, the existing code that checks for the right exception type 
would suffice for my needs.


Cheers everybody!

Uli

Back to comp.lang.python | Previous | NextNext in thread | Find similar | Unroll thread


Thread

unittest: assertRaises() with an instance instead of a type Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-03-28 14:28 +0200
  Re: unittest: assertRaises() with an instance instead of a type Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-28 18:07 +0000
    Re: unittest: assertRaises() with an instance instead of a type Ben Finney <ben+python@benfinney.id.au> - 2012-03-29 12:55 +1100
      Re: unittest: assertRaises() with an instance instead of a type Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-29 06:35 +0000
      Re: unittest: assertRaises() with an instance instead of a type Peter Otten <__peter__@web.de> - 2012-03-29 08:55 +0200
      Re: unittest: assertRaises() with an instance instead of a type Steve Howell <showell30@yahoo.com> - 2012-03-28 22:50 -0700
    Re: unittest: assertRaises() with an instance instead of a type Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-03-29 09:08 +0200
      Re: unittest: assertRaises() with an instance instead of a type Peter Otten <__peter__@web.de> - 2012-03-29 09:48 +0200
      Re: unittest: assertRaises() with an instance instead of a type Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-30 02:45 +0000
        Re: unittest: assertRaises() with an instance instead of a type Ethan Furman <ethan@stoneleaf.us> - 2012-03-30 10:45 -0700
    Re: unittest: assertRaises() with an instance instead of a type Ethan Furman <ethan@stoneleaf.us> - 2012-03-29 08:35 -0700
      Re: unittest: assertRaises() with an instance instead of a type Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-03-30 02:53 +0000
  Re: unittest: assertRaises() with an instance instead of a type Terry Reedy <tjreedy@udel.edu> - 2012-03-28 14:26 -0400
    Re: unittest: assertRaises() with an instance instead of a type Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-03-29 09:28 +0200
      Re: unittest: assertRaises() with an instance instead of a type Terry Reedy <tjreedy@udel.edu> - 2012-03-29 11:04 -0400
    tabs/spaces (was: Re: unittest: assertRaises() with an instance instead of a type) Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-03-29 09:18 +0200
      Re: tabs/spaces (was: Re: unittest: assertRaises() with an instance instead of a type) Roy Smith <roy@panix.com> - 2012-03-29 08:49 -0400
      Re: tabs/spaces Dave Angel <d@davea.name> - 2012-03-29 11:16 -0400
      Re: tabs/spaces Terry Reedy <tjreedy@udel.edu> - 2012-03-29 11:25 -0400
        Re: tabs/spaces Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-03-30 09:05 +0200
          Re: tabs/spaces Dave Angel <d@davea.name> - 2012-03-30 08:47 -0400
            Re: tabs/spaces Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-04-02 09:12 +0200
              Re: tabs/spaces Terry Reedy <tjreedy@udel.edu> - 2012-04-02 03:42 -0400

csiph-web