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


Groups > comp.lang.python > #22330

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

From Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com>
Newsgroups comp.lang.python
Subject Re: unittest: assertRaises() with an instance instead of a type
Date 2012-03-29 09:08 +0200
Message-ID <eced49-sge.ln1@satorlaser.homedns.org> (permalink)
References <pncb49-ur7.ln1@satorlaser.homedns.org> <4f735345$0$29981$c3e8da3$5496439d@news.astraweb.com>

Show all headers | View raw


Am 28.03.2012 20:07, schrieb Steven D'Aprano:
> First off, that is not Python code. "catch Exception" gives a syntax
> error.

Old C++ habits... :|


> Secondly, that is not the right way to do this unit test. You are testing
> two distinct things, so you should write it as two separate tests:
[..code..]
> If foo does *not* raise an exception, the unittest framework will handle
> the failure for you. If it raises a different exception, the framework
> will also handle that too.
>
> Then write a second test to check the exception code:
[...]
> Again, let the framework handle any unexpected cases.

Sorry, you got it wrong, it should be three tests:
1. Make sure foo() raises an exception.
2. Make sure foo() raises the right exception.
3. Make sure the errorcode in the exception is right.

Or maybe you should in between verify that the exception raised actually 
contains an errorcode? And that the errorcode can be equality-compared 
to the expected value? :>

Sorry, I disagree that these steps should be separated. It would blow up 
the code required for testing, increasing maintenance burdens. Which 
leads back to a solution that uses a utility function, like the one you 
suggested or the one I was looking for initially.


> (By the way, I have to question the design of an exception with error
> codes. That seems pretty poor design to me. Normally the exception *type*
> acts as equivalent to an error code.)

True. Normally. I'd adapting to a legacy system though, similar to 
OSError, and that system simply emits error codes which the easiest way 
to handle is by wrapping them.


Cheers!

Uli

Back to comp.lang.python | Previous | NextPrevious in thread | Next 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