Unit Testing: a couple of questions

[Orestis Markou]

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 <manu3d at gmail.com> 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
> --
> http://mail.python.org/mailman/listinfo/python-list
>



-- 
orestis at orestis.gr
http://orestis.gr