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