472,989 Members | 2,687 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,989 software developers and data experts.

How to test that an exception is raised ?

Hi,

I've this module :

from optparse import OptionParser
import re

_version = "P1"

def writeVar(f, line):
"""Output a line in .xml format in the file f."""

f.write('\t<Var>\n')
name = line.split()[0]
adr = line.split()[3]
f.write('\t\t<Name>' + name + '</Name>\n')
f.write('\t\t<Adr>' + adr + '</Adr>\n')
f.write('\t</Var>\n')

def mps2xml(mps,verbose):
"""Convert '.mps' to '.xml'."""

try:
f = open(mps)
f.close()

xmlfile = mps + ".xml"
f = open(xmlfile, "w+")
f.write('<?xml version="1.0" ?>\n')
f.writelines('<List>\n')

pat = re.compile(".*Var.*g.*0x00.*")
lines = list(open(mps))
nbScan = nbFound = 0
for line in lines:
nbScan = nbScan + 1
if pat.match(line):
writeVar(f, line)
nbFound = nbFound + 1

f.writelines('</List>\n')
f.close()

if verbose:
print "Output to file %s..." % xmlfile
print "Lines scanned:", nbScan
print "Lines found:", nbFound

except:
if verbose:
print "FileError"

if __name__ == "__main__":
usage = "usage: %prog [options] filename"
parser = OptionParser(usage)

parser.add_option("-v", "--verbose", action="store_true",
dest="verbose")
parser.add_option("-q", "--quiet", action="store_false", dest="verbose")

(options, args) = parser.parse_args()

if len(args) != 1:
parser.error("incorrect number of arguments")
exit(1)

if options.verbose:
print "mps2xml -", _version

mps2xml(args[0],options.verbose)

And this "unittest" module :

import mps2xml
import os
import unittest

class Tests(unittest.TestCase):

def setUp(self):
self.mps = "test.mps"

def tearDown(self):
pass

def test_badFile(self):
"""Check that an exception is raised if a bad filename is passed to
mps2xml"""
self.assertRaises((IOError),mps2xml.mps2xml, "thisfiledoesntexists",
False)

def test_writeVar_Output(self):
"""Check the output of the 'writeVar' method"""

line = " irM1slotnoisePPtmp Var. g 0x0002F6"
file = open("testWriteVar.xml","w+")
mps2xml.writeVar(file, line)
file.close()

outputlines = list(open("testWriteVar.xml"))
goodlines = list(open("testWriteVar.xml.good"))
self.assertEquals(outputlines, goodlines, 'bad output format')

def test_mps2xml_Creation(self):
"""Check if test.mps.xml is created"""

mps2xml.mps2xml(self.mps, False)
self.assert_(os.path.exists(self.mps + ".xml"), 'test.mps.xml not
created')

if __name__ == '__main__':
unittest.main()

But i've prob with the 1st test : test_badFile.
When I run the test, unittest say that no error is Raised.
But when I run the mps2xml module with a bad file as arg., the exception is
well Raised.

What i'm doing wrong ?

It is because the exception in catched in the mps2xml module ?

Thanks for your helps.

StepH.
Jul 18 '05 #1
8 2676
[snipped alot of codes that doesn't mean much ]

if you want to check for exception then it goes like this

try:
<put your code here which fails on certain exception like maybe IOError>
catch IOError:
<put a code to do something when IOError is raised>

sorry i won't bother to read your code because i can't read, i think i
am tired and need to go to bed. ;-)

--
cheers,
Ishwor Gurung
Jul 18 '05 #2

"StepH" <st***************@bea.be> wrote in message
news:41**********************@feed0.news.be.easyne t.net...
But i've prob with the 1st test : test_badFile.
When I run the test, unittest say that no error is Raised.
But when I run the mps2xml module with a bad file as arg., the exception
is
well Raised.
I assume you don't actually see the exception (you don't see the stack
traceback printed as an output) but you just see your own message
"FileError". That means that the exception was raised and caught by your
try-except statement.
What i'm doing wrong ?

It is because the exception in catched in the mps2xml module ?
With the above mentioned assumption, that must be it. Once the exception is
caught, it is caught and no other code invoking mps2xml.mps2xml (including
the assertRaises in your test) will see the exception.

Your mps2xml.mps2xml function should return a value indicating success or
failure or should re-raise the exception. You need a mechanism to let
invoking code know that it was successful or it failed. With a return code,
you should test that and not the exception. The assert you use should work
if you re-raise the exception.

And BTW, it is a bad idea to use a generic "except" statement like you do.
That catches ALL the exceptions and you will never know if a different
exception than IOError was raised. You should catch only IOError
specifically or any other exception that you may expect. You can add then
an extra "except" statement catching all the other exceptions, but only if
it is essential for your application to handle all exceptions gracefully
instead of just exiting with a stack traceback.
Thanks for your helps.

StepH.

Jul 18 '05 #3
Thanks for you answer.
I'm new to Python (coming from C/C++).
But i've prob with the 1st test : test_badFile.
When I run the test, unittest say that no error is Raised.
But when I run the mps2xml module with a bad file as arg., the exception
is
well Raised.
I assume you don't actually see the exception (you don't see the stack
traceback printed as an output) but you just see your own message
"FileError". That means that the exception was raised and caught by your
try-except statement.


Yes, when i'm run mps2xml.py with a bad filename as arg., the IOError is
launched and is correctly intercepted.
What i'm doing wrong ?

It is because the exception in catched in the mps2xml module ?
With the above mentioned assumption, that must be it. Once the exception

is caught, it is caught and no other code invoking mps2xml.mps2xml (including
the assertRaises in your test) will see the exception.
Do you say that it's not possible to test (using unittest) if an exception
is well raised if the tested code catch it ?
How to solve this paradoxe ? How to automaticaly test such code ?

Your mps2xml.mps2xml function should return a value indicating success or
failure or should re-raise the exception.
1./ Cheking error-return value if not a good idea for me, cause this make
the code less clear. I don't want a code where i've to test each function
return value...
2./ If I re-raise the exception, then how to not show the traceback. My
user will became crazy if they view such error msg.
You need a mechanism to let
invoking code know that it was successful or it failed. With a return code, you should test that and not the exception. The assert you use should work if you re-raise the exception.

And BTW, it is a bad idea to use a generic "except" statement like you do.
That catches ALL the exceptions and you will never know if a different
exception than IOError was raised. You should catch only IOError
specifically or any other exception that you may expect. You can add then
an extra "except" statement catching all the other exceptions, but only if
it is essential for your application to handle all exceptions gracefully
instead of just exiting with a stack traceback.
It seems that there is 2 school here. I've read a lot on python, and somed
'guru' Python say that it's maybe better to use exception even for case you
can "predict", no ? Or i'm completly wrong ?
Thanks for your helps.

StepH.

Thanks again.
StepH.

Jul 18 '05 #4

"StepH" <st***************@bea.be> wrote in message
news:41**********************@feed0.news.be.easyne t.net...

Do you say that it's not possible to test (using unittest) if an exception
is well raised if the tested code catch it ?
How to solve this paradoxe ? How to automaticaly test such code ?
Then you need a side-effect in catching the exception. A return code would
be such a side-effect. Setting a state variable that can be checked by the
invoking code would be another such side-effect.
1./ Cheking error-return value if not a good idea for me, cause this make
the code less clear. I don't want a code where i've to test each function
return value...
2./ If I re-raise the exception, then how to not show the traceback. My
user will became crazy if they view such error msg.
But then how will the user know if the call did what it is supposed to do?
And if the user mis-used the function and used it for a file that does not
exist, how is he/she supposed to know what the problem was and why nothing
is coming out of calling your function?
It seems that there is 2 school here. I've read a lot on python, and
somed
'guru' Python say that it's maybe better to use exception even for case
you
can "predict", no ? Or i'm completly wrong ?


The IOError is an exception that you can predict and I was saying that you
should catch it, but with a "except IOError:" statement instead of the
"except:" statement that you used.
Jul 18 '05 #5
Op 2005-01-28, StepH schreef <st***************@bea.be>:
Thanks for you answer.
I'm new to Python (coming from C/C++).

Do you say that it's not possible to test (using unittest) if an exception
is well raised if the tested code catch it ?
How to solve this paradoxe ? How to automaticaly test such code ?


IMO you want something unittest are not designed for.

Unittest are supposed to test for particular results, not for particular
behaviour within. If the expected behaviour is that calling code doesn't
see an exception raised, then the test passed if no exception was seen.

You equally can't test which branch of an if statement was taken or
which parameter was given to a helper function in order to get to
the desired result.

That you internally raise an exception and catches it, is an
implementation detail, that normally is of no concern to
the tester.

--
Antoon Pardon
Jul 18 '05 #6
Antoon Pardon a écrit :
Op 2005-01-28, StepH schreef <st***************@bea.be>:
Thanks for you answer.
I'm new to Python (coming from C/C++).

Do you say that it's not possible to test (using unittest) if an exception
is well raised if the tested code catch it ?
How to solve this paradoxe ? How to automaticaly test such code ?

IMO you want something unittest are not designed for.


So why the assertRaises function in unittest ? My goal is to test if an
exception is well raised when a bad filename is passed to the mps2xml
function.

Unittest are supposed to test for particular results, not for particular
behaviour within. If the expected behaviour is that calling code doesn't
see an exception raised, then the test passed if no exception was seen.

No (unless i don't well understand you), the expected behavior is to
launch an exception if a bad filename is passed. If no exception is
raised, this is not normal.
You equally can't test which branch of an if statement was taken or
which parameter was given to a helper function in order to get to
the desired result.
I'm agree with out on this point, but not for the exception part...

That you internally raise an exception and catches it, is an
implementation detail, that normally is of no concern to
the tester.


I'll conclude this thred here... In fact, I think I've to go-back to
theory (at least about exception)...

Thanks at all fo trying to help me. I'm new to Python, and i've not
already embrass the "python way" completly.

See you later.

StepH.
Jul 18 '05 #7

"StepH" <st***************@teledisnet.be> wrote in message
news:41***********************@read.news.be.uu.net ...
So why the assertRaises function in unittest ? My goal is to test if an
exception is well raised when a bad filename is passed to the mps2xml
function.


It is for functions in which the exception is raised and not caught. You
can use the exception mechanism to let the code invoking your function know
that something "exceptional" has happened. It means that you "throw" that
exception to the invoking code which has to catch it. Maybe the terminology
is poorly chosen, but assertRaises does not check whether an exception is
raised inside the function but only that an exception is raised (or
"thrown", as described by other languages) from inside the function to
outside. A function does not "throw" an exception if the exception is
caught inside the function. Is that clearer now?

In java for instance, functions are actually declared to "throw" an
exception if any operation inside the function may throw that exception and
the exception is not caught inside the function. If you implement a
function A that invokes another function B and B throws an exception of type
C, then you must catch the exception C in A or you have to declare A that it
"throws C".

Hope this helps.

Dan
Jul 18 '05 #8
Op 2005-01-28, StepH schreef <st***************@teledisnet.be>:
Antoon Pardon a écrit :
Op 2005-01-28, StepH schreef <st***************@bea.be>:
Thanks for you answer.
I'm new to Python (coming from C/C++).

Do you say that it's not possible to test (using unittest) if an exception
is well raised if the tested code catch it ?
How to solve this paradoxe ? How to automaticaly test such code ?

IMO you want something unittest are not designed for.


So why the assertRaises function in unittest?


To see if an exception is propagated to the caller.
My goal is to test if an
exception is well raised when a bad filename is passed to the mps2xml
function.

Unittest are supposed to test for particular results, not for particular
behaviour within. If the expected behaviour is that calling code doesn't
see an exception raised, then the test passed if no exception was seen.


No (unless i don't well understand you), the expected behavior is to
launch an exception if a bad filename is passed. If no exception is
raised, this is not normal.


What do you mean with launch an exception? Should the exception
propagate to the caller or not? If it should your code was wrong
to catch it.
You equally can't test which branch of an if statement was taken or
which parameter was given to a helper function in order to get to
the desired result.


I'm agree with out on this point, but not for the exception part...


Why not? Exceptions are nothing special. Either you want to propagated
them to the caller, in which case they can be seen as somekind of result
and this can be tested for with a unittest or you don't want them to
be propagted and then they are just an implementation detail of your
unit.

--
Antoon Pardon
Jul 18 '05 #9

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

6
by: William Park | last post by:
(crossposted to comp.lang.python, because this may be of interest to them.) Python has try-block, within which you can raise exception. Once it's raised, execution breaks out of the try-block...
8
by: Lonnie Princehouse | last post by:
In a recent post, Michele Simionato asked about resumable (or re-entrant) exceptions, the basic idea being that when raised and uncaught, these exceptions would only propagate backwards through a...
3
by: MackS | last post by:
Hi I'm new to Python and would like to know if the following is possible. Say I have one lower-level object A and one user-interface object B. Suppose B.CallingMethod() calls A.CalledMethod(),...
3
by: mirandacascade | last post by:
Verion of Python: 2.4 O/S: Windows XP ElementTree resides in the c:\python24\lib\site-packages\elementtree\ folder When a string that does not contain well-formed XML is passed as an argument...
5
by: juergen perlinger | last post by:
Hello out there. sometimes I need to have proper control of the floating point arithmetic of the C(and C++) runtime system, and using the f.p. exception handling of the C99 standard is quite...
3
by: elziko | last post by:
I have a procedure that creates a bitmap of a certain size and then displays it in a 3rd party component. However, if the bitmap is very large then a System.OutOfMemoryException is thrown my...
2
by: Abubakar | last post by:
Hi all, I'm writing an app in vc++ 2k5 (all native/unmanaged). This application does a lot of multithreading and socket programming. Its been months since I'm developing this application, at...
132
by: Zorro | last post by:
The simplicity of stack unraveling of C++ is not without defective consequences. The following article points to C++ examples showing the defects. An engineer aware of defects can avoid...
5
by: =?Utf-8?B?c3VydHVyeg==?= | last post by:
Hi, I feel like a noob for asking this. When I publish a VB windows application, I want to disable the ability of the the user to continue when there is an unhandled exception. For example,...
0
by: lllomh | last post by:
Define the method first this.state = { buttonBackgroundColor: 'green', isBlinking: false, // A new status is added to identify whether the button is blinking or not } autoStart=()=>{
0
tracyyun
by: tracyyun | last post by:
Hello everyone, I have a question and would like some advice on network connectivity. I have one computer connected to my router via WiFi, but I have two other computers that I want to be able to...
4
NeoPa
by: NeoPa | last post by:
Hello everyone. I find myself stuck trying to find the VBA way to get Access to create a PDF of the currently-selected (and open) object (Form or Report). I know it can be done by selecting :...
3
NeoPa
by: NeoPa | last post by:
Introduction For this article I'll be using a very simple database which has Form (clsForm) & Report (clsReport) classes that simply handle making the calling Form invisible until the Form, or all...
1
by: Teri B | last post by:
Hi, I have created a sub-form Roles. In my course form the user selects the roles assigned to the course. 0ne-to-many. One course many roles. Then I created a report based on the Course form and...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 1 Nov 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM) Please note that the UK and Europe revert to winter time on...
3
by: nia12 | last post by:
Hi there, I am very new to Access so apologies if any of this is obvious/not clear. I am creating a data collection tool for health care employees to complete. It consists of a number of...
0
NeoPa
by: NeoPa | last post by:
Introduction For this article I'll be focusing on the Report (clsReport) class. This simply handles making the calling Form invisible until all of the Reports opened by it have been closed, when it...
0
isladogs
by: isladogs | last post by:
The next online meeting of the Access Europe User Group will be on Wednesday 6 Dec 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, Mike...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.