Unit Testing: a couple of questions

Antoine De Groote antoine at vo.lu
Tue Oct 28 17:06:46 CET 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