There is no need to provide a separate constructor. Mocking patches your code to replace objects with mocks. Just use the mock.patch() decorator on your test methods; it'll pass in references to the generated mock objects.

Both producer.Producer() and consumer.Consumer() are then mocked out before you create the instance:

from unittest import mock


class MyTest(unittest.TestCase):
    @mock.patch('producer.Producer', autospec=True)
    @mock.patch('consumer.Consumer', autospec=True)
    def test_send_data(self, mock_consumer, mock_producer):
        # configure the consumer instance run method
        consumer_instance = mock_consumer.return_value
        consumer_instance.run.return_value = [
            {u'dataObjectID': u'test1'},
            {u'dataObjectID': u'test2'},
            {u'dataObjectID': u'test3'}]

        coor = MyCoordinator()
        # Create some data and send it to the producer
        for count in range(3):
            coor.sendData('test{}'.format(count) , None)

        # Now verify that the mocks have been called correctly
        mock_producer.assert_has_calls([
            mock.Call('test1', None),
            mock.Call('test2', None),
            mock.Call('test3', None)])

So the moment test_send_data is called, the mock.patch() code replaces the producer.Producer reference with a mock object. Your MyCoordinator class then uses those mock objects rather than the real code. calling producer.Producer() returns a new mock object (the same object that mock_producer.return_value references), etc.

I've made the assumption that producer and consumer are top-level module names. If they are not, provide the full import path. From the mock.patch() documentation:

target should be a string in the form 'package.module.ClassName'. The target is imported and the specified object replaced with the new object, so the target must be importable from the environment you are calling patch() from. The target is imported when the decorated function is executed, not at decoration time.

You can make use of patch (check the docs for it https://docs.python.org/dev/library/unittest.mock.html) and assert that after creating a new instance of the object, the something method was called once and called with the parameters required. For instance, in your example it would be something like this:

from unittest.mock import MagicMock, patch
from your_module import ProductionClass

@patch('your_module.ProductionClass.something')
def test_constructor(something_mock):
    real = ProductionClass()
    assert something_mock.call_count == 1
    assert something_mock.called_with(1,2,3)

The problem is that your MockDataBaseWrapper is totally unrelated to the DataBaseWrapper used in DataModel.

My proposal is to get rid of your MockDataBaseWrapper and:

• If you want to keep your current structure, you can use patch to mock the DataBaseWrapper that is actually imported in data_model.py.

from mock import patch
from my_pkg.data_model import DataModel

def test_data_model():
    with patch("my_pkg.data_model.DataBaseWrapper") as MockedDB:
        mocked_db = MockedDB()
        data_model = DataModel()
        assert data_model.db is mocked_db

The patch context manager will replace the DataBaseWrapper class that gets imported in your data_model.py with a Mock instance and let you interact with that mock, which allows me here to verify that it got instantiated.

Note that it is very important to patch the class in the module where it is imported (and not in the model where it is defined, i.e we patch your_package.data_model.DataBaseWrapper and not your_package.data_base_wrapper.DataBaseWrapper)

• If you don't mind changing your class, then the usual pattern is to inject the db parameter into the constructor of DataModel. Mocking it then becomes a piece of cake.

class DataModel:
    def __init__(self, db):
        self.db = db
        self.db.update_data()

from mock import patch, Mock
from my_pkg.data_model import DataModel

def test_data_model():
    mocked_db = Mock()
    data_model = DataModel(mocked_db)
    assert data_model.db is mocked_db

Since you're only interested in testing one method, why don't you just mock the entire HoldsData class and pin on it the x_coords method?

>>> mock = MagicMock(data={'points': [(0,1), (2,3), (4,5)]})
>>> mock.x_coords = HoldsData.__dict__['x_coords']
>>> mock.x_coords(mock)
[0, 2, 4]

This way you'll have full control over the x_coords input and output (either by side effect or return value).

Note: In py3k you could just do mock.x_coords = HoldsData.x_coords since there are no more unbound methods.

That could also be done in the constructor of the mock object:

MagicMock(data={'points': [(0,1), (2,3), (4,5)]}, x_coords=HoldsData.__dict__['x_coords'])

You have to patch the name, not the instance.

From the official Python documentation: Where to patch

patch() works by (temporarily) changing the object that a name points to with another one. There can be many names pointing to any individual object, so for patching to work you must ensure that you patch the name used by the system under test.

In your example, your class Foo is defined in a module foomod.py, so you have to patch foomod.Bar instead of mod.Bar.

You can put this into a fixture by using the mocker fixture from pytest-mock or with unittest.mock.patch.

@pytest.fixture # With pytest-mock
def mock_bar(mocker):
    return mocker.patch('foomod.Bar')

@pytest.fixture # With stdlib
def mock_bar():
    with patch('foomod.Bar') as mock:
        yield mock

# Usage
def test_foo(mock_bar):
    pass

To my knowledge, there is no significant difference between the two approaches. Both are cleaned up when the fixture goes out of scope.