473,325 Members | 2,671 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

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

Unit Testing: a couple of questions

Hi everybody,

I'm just having a go with Unit Testing for the first time and my
feeling about it in short is: Neat!

I'm a bit worried about the time it's taking me to develop the tests
but after only a day or so I'm already much faster than when I started
with it and the code is already much improved in terms of robustness.
A couple of "philosophical" questions have emerged in the process.

1) Granularity
Given a simple class

class myClass():
def __init__(self, data):
__data = data;

def getData(self):
return __data

def setData(self, data):
__data = data

I've been wondering: where do I stop in terms of testing for things
that could go wrong? In this case for example, it might be reasonable
to expand the class to make sure it only receives integers and test
accordingly, i.e.:

def setData(self, data):
try:
data = int(data)
except ValueError:
raise ValueError("Argument received cannot be converted to
integer: " + data)

But would it be reasonable to test also for the assignment operators?
After all, if, for some strange reason, there isn't enough memory,
couldn't even __data = data potentially fail?

2) Testing in isolation
I'm not entirely clear on this point. I can see how I need to test
each path of the program flow separately. But should a test -only-
rely on the object being tested and mock ones in supporting roles?
I.e. would this be wrong if SupportObject is not a mockup?

def testObjectToBeTested _forReallyBadError(self):
supportObject = SupportObject()
objectToBeTested = ObjectToBeTested()
result = objectToBeTested.addSupportObject(supportObject)
self.failIf(result != kSuccess, "Support Object could not be
added!")

I can see how if the SupportObject class had a bug introduced in it,
this test would fail even though it has nothing to do with the
ObjectToBeTested class. However, creating mock objects can be quite an
overhead (?). I'm wondering if there is a threshold, even a fuzzy one,
under which it isn't worth doing and a test like the one above is
"good enough".

What do you guys think?

Manu
Oct 28 '08 #1
4 1117
I'm wondering if don't want your class to look something like this:

class myClass():
def __init__(self, data):
self.__data = data

def getData(self):
return self.__data

def setData(self, data):
self.__data = data

For the rest I'll let the experts argue, I don't have a lot of
experience with unit testing either... Shame on me! ;-)

Regards,
antoine

Emanuele D'Arrigo wrote:
Hi everybody,

I'm just having a go with Unit Testing for the first time and my
feeling about it in short is: Neat!

I'm a bit worried about the time it's taking me to develop the tests
but after only a day or so I'm already much faster than when I started
with it and the code is already much improved in terms of robustness.
A couple of "philosophical" questions have emerged in the process.

1) Granularity
Given a simple class

class myClass():
def __init__(self, data):
__data = data;

def getData(self):
return __data

def setData(self, data):
__data = data

I've been wondering: where do I stop in terms of testing for things
that could go wrong? In this case for example, it might be reasonable
to expand the class to make sure it only receives integers and test
accordingly, i.e.:

def setData(self, data):
try:
data = int(data)
except ValueError:
raise ValueError("Argument received cannot be converted to
integer: " + data)

But would it be reasonable to test also for the assignment operators?
After all, if, for some strange reason, there isn't enough memory,
couldn't even __data = data potentially fail?

2) Testing in isolation
I'm not entirely clear on this point. I can see how I need to test
each path of the program flow separately. But should a test -only-
rely on the object being tested and mock ones in supporting roles?
I.e. would this be wrong if SupportObject is not a mockup?

def testObjectToBeTested _forReallyBadError(self):
supportObject = SupportObject()
objectToBeTested = ObjectToBeTested()
result = objectToBeTested.addSupportObject(supportObject)
self.failIf(result != kSuccess, "Support Object could not be
added!")

I can see how if the SupportObject class had a bug introduced in it,
this test would fail even though it has nothing to do with the
ObjectToBeTested class. However, creating mock objects can be quite an
overhead (?). I'm wondering if there is a threshold, even a fuzzy one,
under which it isn't worth doing and a test like the one above is
"good enough".

What do you guys think?

Manu
Oct 28 '08 #2
For the first bit, a colleague has recently asked the philosophical
question, "How do you test what happens when the power goes down?" :)

In other words, only test the bits that your code does. If you want to
provide type checking, then yes, you have to test that.

It's fair to assume that everything that is *not* your code will work
as expected. If you do find 3rd-party bugs that affect you, then you
should write a unit test that exposes that bug. When they fix it, your
unittest fails, prompting you to remove any workarounds you had.

On Tue, Oct 28, 2008 at 2:56 PM, Emanuele D'Arrigo <ma****@gmail.comwrote:
Hi everybody,

I'm just having a go with Unit Testing for the first time and my
feeling about it in short is: Neat!

I'm a bit worried about the time it's taking me to develop the tests
but after only a day or so I'm already much faster than when I started
with it and the code is already much improved in terms of robustness.
A couple of "philosophical" questions have emerged in the process.

1) Granularity
Given a simple class

class myClass():
def __init__(self, data):
__data = data;

def getData(self):
return __data

def setData(self, data):
__data = data

I've been wondering: where do I stop in terms of testing for things
that could go wrong? In this case for example, it might be reasonable
to expand the class to make sure it only receives integers and test
accordingly, i.e.:

def setData(self, data):
try:
data = int(data)
except ValueError:
raise ValueError("Argument received cannot be converted to
integer: " + data)

But would it be reasonable to test also for the assignment operators?
After all, if, for some strange reason, there isn't enough memory,
couldn't even __data = data potentially fail?

2) Testing in isolation
I'm not entirely clear on this point. I can see how I need to test
each path of the program flow separately. But should a test -only-
rely on the object being tested and mock ones in supporting roles?
I.e. would this be wrong if SupportObject is not a mockup?

def testObjectToBeTested _forReallyBadError(self):
supportObject = SupportObject()
objectToBeTested = ObjectToBeTested()
result = objectToBeTested.addSupportObject(supportObject)
self.failIf(result != kSuccess, "Support Object could not be
added!")

I can see how if the SupportObject class had a bug introduced in it,
this test would fail even though it has nothing to do with the
ObjectToBeTested class. However, creating mock objects can be quite an
overhead (?). I'm wondering if there is a threshold, even a fuzzy one,
under which it isn't worth doing and a test like the one above is
"good enough".

What do you guys think?

Manu
--
http://mail.python.org/mailman/listinfo/python-list


--
or*****@orestis.gr
http://orestis.gr
Oct 28 '08 #3
Mel
Emanuele D'Arrigo wrote:
I'm a bit worried about the time it's taking me to develop the tests
but after only a day or so I'm already much faster than when I started
with it and the code is already much improved in terms of robustness.
A couple of "philosophical" questions have emerged in the process.
[ ... ]
But would it be reasonable to test also for the assignment operators?
After all, if, for some strange reason, there isn't enough memory,
couldn't even __data = data potentially fail?
I would say, don't test for anything you can't fix. If you have (what the
agile-programming people call) a "user story" describing how your program
will recover from out-of-memory, then test whether that recovery is carried
out. Otherwise forget it.

Best think of unit tests as your sub-program spec written in a different
form: i.e. as executable programs. You don't test for "things that can go
wrong", you test for behaviour that your program must exhibit.
>
2) Testing in isolation
I'm not entirely clear on this point. I can see how I need to test
each path of the program flow separately. But should a test -only-
rely on the object being tested and mock ones in supporting roles?
I.e. would this be wrong if SupportObject is not a mockup?

def testObjectToBeTested _forReallyBadError(self):
supportObject = SupportObject()
objectToBeTested = ObjectToBeTested()
result = objectToBeTested.addSupportObject(supportObject)
self.failIf(result != kSuccess, "Support Object could not be
added!")

I can see how if the SupportObject class had a bug introduced in it,
this test would fail even though it has nothing to do with the
ObjectToBeTested class. However, creating mock objects can be quite an
overhead (?). I'm wondering if there is a threshold, even a fuzzy one,
under which it isn't worth doing and a test like the one above is
"good enough".
I have heard people talk, matter-of-factly about support objects that got so
complicated that they needed unit tests of their own. Of course, anything
can be done in a ridiculous way, but good comprehensive unit tests give you
the eternal assurance that your program is behaving properly, through all
maintenance and modification. That's worth a lot.

Oct 28 '08 #4
Thank you all for the very instructive replies! Much appreciated!

By the sound of it I just have to relax a little and acquire a little
bit more experience on the matter as I go along. =)

Thank you again!

Manu
Oct 30 '08 #5

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

Similar topics

4
by: Hugh Cowan | last post by:
Hello, I don't program full-time (anymore), but I do try and stay on-top of the latest technologies and like most are always trying to upgrade my skills and remain current (as much as is...
38
by: Christoph Zwerschke | last post by:
In August 2001, there was a thread about the "Art of Unit Testing": http://groups.google.com/group/comp.lang.python/browse_frm/thread/aa2bd17e7f995d05/71a29faf0a0485d5 Paul Moore asked the...
1
by: serge | last post by:
I've started researching on Unit Testing and I must admit I had never heard of Unit Testing until a couple of months ago. Obviously I am interested in Unit Testing Stored Procedures. I read the...
2
by: Naveen Mukkelli | last post by:
Hi, I'm writing a client/server application using C#. The server accepts connecitons asynchronously, using BeginAccept/EndAccept. Is there any way we can write some unit tests(NUnit) to test...
72
by: Jacob | last post by:
I have compiled a set og unit testing recommendations based on my own experience on the concept. Feedback and suggestions for improvements are appreciated: ...
7
by: Diffident | last post by:
Hello All, Can anyone please suggest me a good unit testing tool. I have seen NUnit but not sure on how I can use it to test my methods which involve session variables, viewstate variables,...
176
by: nw | last post by:
Hi, I previously asked for suggestions on teaching testing in C++. Based on some of the replies I received I decided that best way to proceed would be to teach the students how they might write...
4
by: cmay | last post by:
I have been looking on and off for the past 6 months or so for some kind of guidance for creating asp.net unit tests with Visual Studio Team System, but I have yet to find anything significant. ...
10
by: Brendan Miller | last post by:
What would heavy python unit testers say is the best framework? I've seen a few mentions that maybe the built in unittest framework isn't that great. I've heard a couple of good things about...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

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.