Unit Testing: a couple of questions

[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.