Unit Testing: a couple of questions
Antoine De Groote
antoine at vo.lu
Tue Oct 28 12:06:46 EDT 2008
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
More information about the Python-list
mailing list