我有以下兩種方法（簡化）：
def func_a(u, v, w, x, y, z):
##Do some irrelevant stuff
newVariable = func_b(u, v, w, y)
##Do some more irrelevant stuff
def func_b(u, v, w, y):
##Do some manipulation of the variables
##Call some more methods, like func_c, func_d, func_e
newVariable = 1 #In reality; some value that is calculated
return newVariable
func_a 相當簡單，但 func_b 會根據某些標準呼叫一些不同的方法，這些在此處不相關。此功能在未來很可能會發生變化，因為它的計算特征可能會在專案的后期階段發生變化。我的問題如下：
借助Pytest和Mock，我們可以輕松測驗func_a的功能；您可以模擬 func_b 并設定 return_value。
從 func_a 中檢查 func_b 是否被正確呼叫也很容易；使用 assert_call_with 我們可以確保在呼叫函式時使用預期值，如下所示：
@patch('func_b')
def test_func_a_calls_func_b_correctly(b_mock):
func_a(1,2,3,4,5,6)
b_mock.assert_called_with(1, 2, 3, 5)
但是，如果我們改變 func_b 的定義（例如改為: func_b(u, v, w, y, q)，這個測驗仍然會通過，因為 func_a 中的呼叫仍然“如預期”。這當然不是我們想要的，因為測驗會通過，但是程式在運行時會崩潰。有沒有辦法以這種方式測驗方法定義的更改？
如果沒有，最好的測驗是不是模擬 func_b，而是模擬在 func_b 中呼叫的 func_c、func_d 和 func_e？這當然可以正常作業，但對于單元測驗來說似乎不是很干凈。
uj5u.com熱心網友回復：
這與任何事情一樣都是一個哲學問題 -mock不是為了模擬它正在替換的功能，只是提供一個假的輸入和輸出來看看它是如何被呼叫的。
如果您確實需要確保您的代碼對函式的呼叫仍然“匹配”函式的行為，那么您必須在測驗時將原始函式與mock（或呼叫）進行比較。
例如，在您當前的示例中，您可以執行以下操作：
from inspect import signature
@patch('func_b')
def test_func_a_calls_func_b_correctly(b_mock):
func_a(1,2,3,4,5,6)
# Check that the number of params passed when calling func_b
# is the same as the number of parameters that the 'real' func_b expects
assert len(mock.call_args.args) == len(signature(func_b).parameters)
但是，這并不能防止引數更改的順序或“目的”，這需要進一步檢查func_b.
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/370990.html
上一篇：控制臺目標日志記錄不適用于NUnit測驗用例源提供程式中呼叫的方法
下一篇：編譯Java單元測驗非常慢