MockObject Suport For unittest.TestCase

Matt Russell matt at teaphoo.fsnet.co.uk
Fri Mar 21 04:42:09 EST 2003


mcherm at mcherm.com wrote in message news:<mailman.1048186475.2042.python-list at python.org>...
> Matt:
> 
> GREAT CONTRIBUTION!
> 
> I think that mock objects is a feature that could be very useful, and
> a handy way to build them inside the unittest module sounds like a
> greate idea. And we appreciate your effort to contribute!
> 
> I haven't finished looking over your patch yet, but I have a couple
> of suggestions right fron the beginning.
> 
> (1) I would change self.called (which is private storage for the mock
>    object) to something like self.__mockObject_called to reduce the chance
>    of an unfortunate name collision.

Thanks for your input Mark! (i agree and will make the change to my
patch)


> 
> (2) In MockFactory.__new__ I would try to check for classes implementing
>    custom __getattr__, and __getattribute__ methods, and handle those
>    specially (probably by raising an exception claiming that the class
>    can't be mocked).

Yes, classes that use very pythonic mechanisms need to be handled by
the author of the unittest; - given a class

class Test:
    def __init__(self):
        self.obj = SomeObj()
    def __getattr__(self, name):
        return getattr(sefl.ob, name)


- I would suggest mocking self.obj in Test....(assuming of couse that
the author *knows* that self.obj in Test itself does not implemnet any
special __hook__)

i.e
class MTC(TestCase):
    def testSomeMethod(self):
          myObj = Test()
          myObj.obj = self.createMockInstance(SomeObj, [...])
          # asserts...

> 
> I'm sure there'll be other suggestions from other people, and perhaps
> some more from me if I get more time.
> 
> -- Michael Chermside




More information about the Python-list mailing list