[Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement) (original) (raw)
Ron Adam rrr at ronadam.com
Thu Jul 17 18:19:57 CEST 2008
- Previous message: [Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement)
- Next message: [Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Nick Coghlan wrote:
Taking an existing function such as assertRaises and going "hey, we aren't using the return value from this, wouldn't it be really convenient if it told us the exact exception it actually caught?" doesn't cause any problems for existing code, and makes it much easier to write tests that need to check additional details about the exception that is raised (e.g. to check that the correct error code is captured and reported for things like OSError).
The essence of the function remains unchanged - you're still asserting that a particular exception is raised. Returning the actual exception object that was caught is merely a convenience that makes a lot of sense.
I'm not sure I understand...
If "a particular exception is raised", every thing is good and there is no error to report. ie... the code being tested did the right thing.
If it does not raise the particular desired exception, isn't either a failureException raised or someother exception, which is caught by the unittest test runner. In that case the assertRaises method never gets a chance to return anything.
If this is correct, then the exception needs to be caught and passed out via the failureException, and not the returned value.
Ron
- Previous message: [Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement)
- Next message: [Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]