如何模拟单例类方法

Question

Suppose we have the following structure:

class A():
    class __A():
        def __to_be_mocked(self):
            #something here
    def __init__(self):
        with A.lock:
            if not A.instance:
                A.instance = A.__A()

    def __getattr__(self,name):
        return getattr(self.instance,name)

Now we want to mock the function __to_be_mocked .How can we mock it as the target accepted by mock.patch.object is package.module.ClassName .I have tried all methods like

target = A.__A
target = A.___A

and many more.

EDIT:

I solved it using

target=A._A__A and attribute as '_A__to_be_mocked`

Now the question is __to_be_mocked is inside __A so shouldn't it be ___A__to_be_mocked .

Is it because of setattribute in A or __init__ in A?

Answer 1

I mocked a lot of things in python and after did it lot of times I can say:

1. NEVER mock/patch __something attributes (AKA private attributes)
2. AVOID to mock/patch _something attributes (AKA protected attributes)

Private

If you mock private things you'll tangled production and test code. When you do this kind of mocks there is always a way to obtain the same behavior by patching or mocking public or protected stuffs.

To explain better what I mean by tangling production and test code I can use your example: to patch A.__B.__to_be_mocked() (I replaced __A inner class by __B to make it more clear) you need to write something like

patch('amodule.A._A__B._B__to_be_mocked')

Now by patching __to_be_mocked you are spreading A , B and to_be_mocked names in your test: that is exactly what I mean to tangled code. So if you need to change some name you should go in all your test and change your patches and no refactoring tool can propose to you to change _A__B._B string.

Now if you are a good guy and take your tests clean you can have just a few points where these names come out but if it is a singleton I can bet that it will spot out like mushrooms.

I would like to point out that private and protected have nothing to do with some security concern but are just way to make your code more clear. That point is crystal clear in python where you don't need to be a hacker to change private or protected attributes: these conventions are here just to help you on reading code where you can say Oh great! I don't need to understand what is it ... it just the dirty work . IMHO private attributes in python fails this goal ( __ is too long and see it really bother me) and protected are just enough.

Side note: little example to understand python's private naming:

>>> class A():
...  class __B():
...   def __c(self):
...    pass
... 
>>> a = A()
>>> dir(a)
['_A__B', '__doc__', '__module__']
>>> dir(a._A__B)
['_B__c', '__doc__', '__module__']

To come back at your case: How your code use __to_be_mocked() method? is it possible to have the same effect by patch/mock something else in A (and not A.__A ) class?

Finally, if you are mocking private method to sense something to test you are in the wrong place: never test the dirty work it should/may/can change without change your tests. What you need is to test code behavior and not how it is written.

Protected

If you need test, patch or mock protected stuffs maybe your class hide some collaborators: test it and use your test to refactor your code then clean your tests.

Disclaimer

Indeed: I spread this kind of crap in my tests and then I fight to remove it when I understand that I can do it better.

Answer 2

Class & instance members starting with double underscores have their names rewritten to prevent collisions with same-name members in parent classes, making them behave as if "private". So __B here is actually accessible as A._A__B . (Underscore, class name, double underscored member name). Note that if you use the single-underscore convention ( _B ), no rewriting happens.

That being said, you'll rarely see anyone actually use this form of access and especially not in prod code as things are made "private" for a reason. For mocking, maybe, if there's no better way.