Aktivieren aufeinanderfolgender Aufrufe einer Scheinmethode

Mock hat eine hilfreiche assert_called_with()Methode . Soweit ich weiß, überprüft dies jedoch nur den letzten Aufruf einer Methode.
Wenn ich Code habe, der die verspottete Methode dreimal hintereinander aufruft, jedes Mal mit unterschiedlichen Parametern, wie kann ich diese drei Aufrufe mit ihren spezifischen Parametern bestätigen?

assert_has_calls ist ein weiterer Ansatz für dieses Problem.

Aus den Dokumenten:

assert_has_calls (Aufrufe, any_order = False)

Bestätigen Sie, dass der Mock mit den angegebenen Aufrufen aufgerufen wurde. Die Liste mock_calls wird auf Aufrufe überprüft.

Wenn any_order False ist (Standardeinstellung), müssen die Aufrufe sequentiell sein. Vor oder nach den angegebenen Anrufen können zusätzliche Anrufe erfolgen.

Wenn any_order True ist, können die Aufrufe in beliebiger Reihenfolge erfolgen, sie müssen jedoch alle in mock_calls angezeigt werden.

Beispiel:

>>> from unittest.mock import call, Mock
>>> mock = Mock(return_value=None)
>>> mock(1)
>>> mock(2)
>>> mock(3)
>>> mock(4)
>>> calls = [call(2), call(3)]
>>> mock.assert_has_calls(calls)
>>> calls = [call(4), call(2), call(3)]
>>> mock.assert_has_calls(calls, any_order=True)

Quelle: https://docs.python.org/3/library/unittest.mock.html#unittest.mock.Mock.assert_has_calls

Normalerweise ist mir die Reihenfolge der Anrufe egal, nur dass sie passiert sind. In diesem Fall verbinde ich mich assert_any_callmit einer Behauptung über call_count.

>>> import mock
>>> m = mock.Mock()
>>> m(1)
<Mock name='mock()' id='37578160'>
>>> m(2)
<Mock name='mock()' id='37578160'>
>>> m(3)
<Mock name='mock()' id='37578160'>
>>> m.assert_any_call(1)
>>> m.assert_any_call(2)
>>> m.assert_any_call(3)
>>> assert 3 == m.call_count
>>> m.assert_any_call(4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "[python path]\lib\site-packages\mock.py", line 891, in assert_any_call
    '%s call not found' % expected_string
AssertionError: mock(4) call not found

Ich finde es einfacher zu lesen und zu verstehen als eine große Liste von Aufrufen, die an eine einzelne Methode übergeben werden.

Wenn Sie sich für die Bestellung interessieren oder mehrere identische Anrufe erwarten, ist dies assert_has_callsmöglicherweise besser geeignet.

Bearbeiten

Seit ich diese Antwort gepostet habe, habe ich meinen Testansatz im Allgemeinen überdacht. Ich denke, es ist erwähnenswert, dass Sie möglicherweise unangemessen testen oder ein Designproblem haben, wenn Ihr Test so kompliziert wird. Mocks dienen zum Testen der Kommunikation zwischen Objekten in einem objektorientierten Design. Wenn Ihr Design nicht objektorientiert ist (wie bei mehr prozeduralen oder funktionalen), ist das Modell möglicherweise völlig unangemessen. Möglicherweise ist in der Methode auch zu viel los, oder Sie testen interne Details, die am besten nicht verspottet werden. Ich habe die in dieser Methode erwähnte Strategie entwickelt, als mein Code nicht sehr objektorientiert war, und ich glaube, ich habe auch interne Details getestet, die am besten nicht verspottet worden wären.

Mit dem Mock.call_args_listAttribut können Sie Parameter mit früheren Methodenaufrufen vergleichen. Das in Verbindung mit Mock.call_countAttribut sollte Ihnen die volle Kontrolle geben.

Ich muss das immer wieder nachschlagen, also hier ist meine Antwort.

Das Aktivieren mehrerer Methodenaufrufe für verschiedene Objekte derselben Klasse

Angenommen, wir haben eine Hochleistungsklasse (die wir verspotten wollen):

In [1]: class HeavyDuty(object):
   ...:     def __init__(self):
   ...:         import time
   ...:         time.sleep(2)  # <- Spends a lot of time here
   ...:     
   ...:     def do_work(self, arg1, arg2):
   ...:         print("Called with %r and %r" % (arg1, arg2))
   ...:  

Hier ist ein Code, der zwei Instanzen der HeavyDutyKlasse verwendet:

In [2]: def heavy_work():
   ...:     hd1 = HeavyDuty()
   ...:     hd1.do_work(13, 17)
   ...:     hd2 = HeavyDuty()
   ...:     hd2.do_work(23, 29)
   ...:    

Hier ist ein Testfall für die heavy_workFunktion:

In [3]: from unittest.mock import patch, call
   ...: def test_heavy_work():
   ...:     expected_calls = [call.do_work(13, 17),call.do_work(23, 29)]
   ...:     
   ...:     with patch('__main__.HeavyDuty') as MockHeavyDuty:
   ...:         heavy_work()
   ...:         MockHeavyDuty.return_value.assert_has_calls(expected_calls)
   ...:  

Wir verspotten die HeavyDutyKlasse mit MockHeavyDuty. Um Methodenaufrufe zu bestätigen, die von jeder HeavyDutyInstanz kommen, müssen wir MockHeavyDuty.return_value.assert_has_callsstattdessen auf verweisen MockHeavyDuty.assert_has_calls. Außerdem müssen expected_callswir in der Liste von angeben, für welchen Methodennamen wir Aufrufe geltend machen möchten. Unsere Liste besteht also nicht nur aus Anrufen call.do_work, sondern aus Anrufencall .

Das Ausüben des Testfalls zeigt uns, dass es erfolgreich ist:

In [4]: print(test_heavy_work())
None

Wenn wir die heavy_workFunktion ändern , schlägt der Test fehl und es wird eine hilfreiche Fehlermeldung ausgegeben:

In [5]: def heavy_work():
   ...:     hd1 = HeavyDuty()
   ...:     hd1.do_work(113, 117)  # <- call args are different
   ...:     hd2 = HeavyDuty()
   ...:     hd2.do_work(123, 129)  # <- call args are different
   ...:     

In [6]: print(test_heavy_work())
---------------------------------------------------------------------------
(traceback omitted for clarity)

AssertionError: Calls not found.
Expected: [call.do_work(13, 17), call.do_work(23, 29)]
Actual: [call.do_work(113, 117), call.do_work(123, 129)]

Aktivieren mehrerer Aufrufe einer Funktion

Im Gegensatz dazu sehen Sie hier ein Beispiel, das zeigt, wie mehrere Aufrufe einer Funktion verspottet werden:

In [7]: def work_function(arg1, arg2):
   ...:     print("Called with args %r and %r" % (arg1, arg2))

In [8]: from unittest.mock import patch, call
   ...: def test_work_function():
   ...:     expected_calls = [call(13, 17), call(23, 29)]    
   ...:     with patch('__main__.work_function') as mock_work_function:
   ...:         work_function(13, 17)
   ...:         work_function(23, 29)
   ...:         mock_work_function.assert_has_calls(expected_calls)
   ...:    

In [9]: print(test_work_function())
None

Es gibt zwei Hauptunterschiede. Die erste ist, dass wir beim Verspotten einer Funktion unsere erwarteten Aufrufe mit callanstatt mit verwenden call.some_method. Das zweite ist , dass wir rufen Sie assert_has_callsauf mock_work_function, anstatt auf mock_work_function.return_value.