В комментариях к вопросу они сказали, что это не то, для чего предназначены модульные тесты. Да, это делает тесты хрупкими. Но они служат реальному использованию: правильно ли я реализую блокировку. Возможно, вы захотите реорганизовать свой класс, чтобы его было легче тестировать (и это был бы еще один интересный вопрос).

Но если вы действительно хотите проверить это как есть, у меня есть решение для вас.

Что нам нужно, так это шпионить за тремя методами self.__lock.acquire, self.__lock.release и self.__atomic_method_1. Один из способов сделать это — обернуть вокруг них Mock и записать поведение. Но просто знать, что их призвали, недостаточно, вам нужен порядок между ними. Поэтому вам нужно несколько шпионов, которые коллективно регистрируют происходящие действия.

import unittest
from unittest import mock
from class_a import A
import threading

class TestCallOrder(unittest.TestCase):
    def test_call_order(self):
        sut = A(threading.Lock())

        # bypass the "name mangling" due to leading "__"
        sut_lock = sut._A__lock
        sut_method = sut._A__atomic_method_1

        # store what we observed during the test
        observed = []

        # prepare the side effects : they are simply observing the call, then forwarding it to the actual function
        def lock_acquire_side_effect():
            observed.append("lock acquired")
            sut_lock.acquire()
        def lock_release_side_effect():
            observed.append("lock released")
            sut_lock.release()
        def method_side_effect(*args, **kwargs):
            observed.append("method called")
            sut_method(*args, **kwargs)

        # prepare the spies, one on the lock, one on the method
        # (we could also mock the two Lock methods separately)
        lock_spy = mock.Mock(wraps=sut_lock, **{"acquire.side_effect": lock_acquire_side_effect,
                                                "release.side_effect": lock_release_side_effect})
        method_spy = mock.Mock(wraps=sut_method, **{"side_effect": method_side_effect})
        # they are wrapping the actual object, so method calls and attribute access are forwarded to it
        # but we also configure them, for certain calls, to use a special side effect (our spy functions)
        with mock.patch.object(sut, "_A__lock", lock_spy):
            with mock.patch.object(sut, "_A__atomic_method_1", method_spy):
            # we apply both spies (with Python 3.10 you can do it with only one `with`)
                sut.method_1()
                self.assertEqual(["lock acquired", "method called", "lock released"], observed)
                # and we check against a very nice ordered log of observations

if __name__ == '__main__':
    unittest.main()

Редактировать

Чтобы лучше объяснить, что я сделал, вот схема того, как вещи связаны без моков:

Ваш SUT имеет две ссылки:

• один с именем __locked, который указывает на его экземпляр Lock, который сам имеет (на наш взгляд) 2 ссылки: acquire и release
• другой с именем __atomic_method_1, который указывает на его A.__atomic_method_1 метод

Мы хотим наблюдать за вызовами __lock.acquire, __lock.release, __atomic_method_1 и их относительным порядком.

Более простой способ сделать то, что я мог придумать, - заменить каждую из этих трех «шпионскими функциями», которые записывают, как они вызывались (просто добавляя в список), а затем перенаправлять вызов фактической функции.

Но тогда нам нужно, чтобы эти функции вызывались, поэтому нам придется издеваться над вещами. Поскольку они не являются «импортируемыми», мы не можем их mock.patch . Но у нас есть фактический объект, над которым мы хотим издеваться, и это именно то, для чего предназначен mock.patch.object! Находясь в with, sut.something будет заменен макетом. Итак, нам нужно два макета, один для __atomic_method_1, другой для __lock.

Насколько я могу судить, мы не будем использовать __atomic_method_1 каким-либо другим способом, кроме его вызова. Поэтому мы просто хотим, чтобы вместо этого наш макет вызывал наш шпионский метод. Для этого мы можем настроить его для вызова функции при ее вызове, обозначенной "side_effect".

Но есть много других способов, которыми мы можем использовать наш __lock помимо acquire-ing и release-ing его. Мы не знаем, что __aotmic_method_1 сделает с этим. Поэтому, чтобы быть уверенным, мы установим mock для пересылки всего фактическому объекту, что означает, что это wraps оно.

Что дает нам это:

Звонки на __lock.acquire и __lock.release как бы перенаправляются (благодаря насмешкам) через нашего шпиона, в то время как все остальные по-прежнему проходят нормально.

_{(We could have done without creating a Mock for __aotmic_method_1, and mock.patch.object with the spy function)}

Решение @Lenormju явно богато концепциями о Mocking и, на мой взгляд, предпочтительнее этого. На самом деле я принял это. Однако я предлагаю другой ответ, который можно использовать для решения некоторых проблем тестирования и моего конкретного тестового примера.

Метод тестирования, который я написал, основан на следующих идеях:

1. создайте экземпляр Mock методом mock.create_autospec():

mock_a = mock.create_autospec(A)

2. вызвать метод экземпляра method_1() классом A и передать ему экземпляр Mock:

A.method_1(mock_a)

Полный тестовый файл выглядит следующим образом:

import unittest
from unittest import mock
from class_a import A

class MyTestCase(unittest.TestCase):
    def test_call_order(self):
        mock_a = mock.create_autospec(A)
        expected = [mock.call._A__lock.acquire(),
                    mock.call._A__atomic_method_1(),
                    mock.call._A__lock.release()]
        A.method_1(mock_a)
        self.assertEqual(expected, mock_a.mock_calls)

if __name__ == '__main__':
    unittest.main()

Тест не использует экземпляр тестируемого класса

Одна из проблем этого теста заключается в том, что он не создает экземпляр class A и, следовательно, вызывает method_1() по-другому в отношении производственного кода.

С другой стороны, это специальный тест, который я должен использовать для проверки статической структуры кода method_1(), поэтому, на мой взгляд, и только в этом конкретном случае, трюк может быть приемлемым.