誰在「不要模擬第三方」和「確保close（）被稱爲」之間的戰鬥中獲勝？

Question

我有這個代碼塊我想單元測試：

@staticmethod 
def _read_from_zip(pkg_zip_path): 
    """ 
    Return a |BlobCollection| instance loaded from *pkg_zip_path*. 
    """ 
    blobs = BlobCollection() 
    zipf = ZipFile(pkg_zip_path) 
    for name in zipf.namelist(): 
     blobs[name] = zipf.read(name) 
    zipf.close() 
    root_uri = os.path.splitext(pkg_zip_path)[0] 
    return PhysPkg(blobs, root_uri) 

它調用ZipFile中，圖書館/第三方軟件包，所以我想寫一個測試，用ZipFile的整合，而不是嘲笑它（不要模擬第三方代碼規則）。

這是我迄今爲止的測試。 initializer_mock()是一個輔助功能，在這種情況下，修補的方法__init__()一類，PhysPkg：

from opcdiag.phys_pkg import PhysPkg 

MINI_PKG_PATH = 'test_files/mini_pkg.zip' 

@pytest.fixture 
def init(self, request): 
    return initializer_mock(PhysPkg, request) 

def it_can_construct_from_a_zip_package(self, init): 
    PhysPkg._read_from_zip(MINI_PKG_PATH) 
    expected_blobs = {'uri_1': b'blob_1\n', 'uri_2': b'blob_2\n'} 
    init.assert_called_once_with(expected_blobs, ROOT_URI) 

的問題是，因爲我不嘲笑ZipFile中，我不知道怎樣才能測試該close()方法被調用。

也許我應該寫兩個測試？這一個通過測試結果確保與ZipFile的正確集成，另一個通過嘲弄ZipFile來確保close()被調用？

Answer 1

是的，你應該寫2個測試。或者，您可以爲您的圖書館創建一個代理，轉發每種方法，但要計算已調用close的次數。

我用字proxy而不是mock是有原因的。你不會取代它（因爲模擬對象通常會這樣做）。你只是添加一個透明的圖層。

「你不要模擬第三方庫」的原因是你需要測試它們（特別是當你更新它們或可能想更新它們時）。一種選擇是信任提供者。另一個是創建一個完整的測試。第三個（是的，由「不模仿第三方庫」推廣的）只是在你的軟件有效使用它們的方面進行測試。 A proxy mock不會改變這一點。