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 "philosophi cal" 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("Arg ument 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 testObjectToBeT ested _forReallyBadEr ror(self):
supportObject = SupportObject()
objectToBeTeste d = ObjectToBeTeste d()
result = objectToBeTeste d.addSupportObj ect(supportObje ct)
self.failIf(res ult != 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
ObjectToBeTeste d 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
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 "philosophi cal" 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("Arg ument 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 testObjectToBeT ested _forReallyBadEr ror(self):
supportObject = SupportObject()
objectToBeTeste d = ObjectToBeTeste d()
result = objectToBeTeste d.addSupportObj ect(supportObje ct)
self.failIf(res ult != 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
ObjectToBeTeste d 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
Comment