利用Python中的mock庫(kù)對(duì)Python代碼進(jìn)行模擬測(cè)試
如何不靠耐心測(cè)試
通常，我們編寫的軟件會(huì)直接與那些我們稱之為“骯臟的”服務(wù)交互。通俗地說，服務(wù)對(duì)我們的應(yīng)用來說是至關(guān)重要的，它們之間的交互是我們?cè)O(shè)計(jì)好的，但這會(huì)帶來我們不希望的副作用——就是那些在我們自己測(cè)試的時(shí)候不希望的功能。
比如，可能我們正在寫一個(gè)社交軟件并且想測(cè)試一下“發(fā)布到Facebook的功能”，但是我們不希望每次運(yùn)行測(cè)試集的時(shí)候都發(fā)布到Facebook上。
Python的unittest庫(kù)中有一個(gè)子包叫unittest.mock——或者你把它聲明成一個(gè)依賴，簡(jiǎn)化為mock——這個(gè)模塊提供了非常強(qiáng)大并且有用的方法，通過它們可以模擬或者屏敝掉這些不受我們希望的方面。
注意：mock是最近收錄在Python 3.3標(biāo)準(zhǔn)庫(kù)中的；之前發(fā)布的版本必須通過 PyPI下載Mock庫(kù)。
恐懼系統(tǒng)調(diào)用
再舉一個(gè)例子，考慮系統(tǒng)調(diào)用，我們將在余下的文章中討論它們。不難發(fā)現(xiàn)，這些都可以考慮使用模擬：無論你是想寫一個(gè)腳本彈出一個(gè)CD驅(qū)動(dòng)，或者是一個(gè)web服務(wù)用來刪除/tmp目錄下的緩存文件，或者是一個(gè)socket服務(wù)來綁定一個(gè)TCP端口，這些調(diào)用都是在你單元測(cè)試的時(shí)候是不被希望的方面。
作為一個(gè)開發(fā)人員，你更關(guān)心你的庫(kù)是不是成功的調(diào)用了系統(tǒng)函數(shù)來彈出CD，而不是體驗(yàn)每次測(cè)試的時(shí)候CD托盤都打開。
作為一個(gè)開發(fā)人員，你更關(guān)心你的庫(kù)是不是成功調(diào)用了系統(tǒng)函數(shù)來彈出CD（帶著正確的參數(shù)等）。而不是體驗(yàn)每次測(cè)試的時(shí)候CD托盤都打開（或者更糟，很多次，當(dāng)一個(gè)單元測(cè)試運(yùn)行的時(shí)候，很多測(cè)試點(diǎn)都涉及到了彈出代碼）。
同樣地，保持你的單元測(cè)試效率和性能意味著要還要保留一些自動(dòng)化測(cè)試之外的“緩慢代碼”，比如文件系統(tǒng)和網(wǎng)絡(luò)的訪問。
對(duì)于我們的第一個(gè)例子，我們要重構(gòu)一個(gè)從原始到使用mock的一個(gè)標(biāo)準(zhǔn)Python測(cè)試用例。我們將會(huì)證明如何用mock寫一個(gè)測(cè)試用例使我們的測(cè)試更智能、更快，并且能暴露更多關(guān)于我們的軟件工作的問題。
一個(gè)簡(jiǎn)單的刪除功能
有時(shí)，我們需要從文件系統(tǒng)中刪除文件，因此，我們可以寫這樣的一個(gè)函數(shù)在Python中，這個(gè)函數(shù)將使它更容易成為我們的腳本去完成這件事情。
#!/usr/bin/env python# -*- coding: utf-8 -*-import osdef rm(filename): os.remove(filename)
很明顯，在這個(gè)時(shí)間點(diǎn)上，我們的rm方法不提供比基本os.remove方法更多的功能，但我們的代碼將會(huì)有所改進(jìn)，允許我們?cè)谶@里添加更多的功能。
讓我們寫一個(gè)傳統(tǒng)的測(cè)試用例，即，不用模擬測(cè)試：
#!/usr/bin/env python# -*- coding: utf-8 -*-from mymodule import rmimport os.pathimport tempfileimport unittestclass RmTestCase(unittest.TestCase):
tmpfilepath = os.path.join(tempfile.gettempdir(), "tmp-testfile") def setUp(self):
with open(self.tmpfilepath, "wb") as f:
f.write("Delete me!")
def test_rm(self):
# remove the file
rm(self.tmpfilepath) # test that it was actually removed
self.assertFalse(os.path.isfile(self.tempfile), "Failed to remove the file.")
我們的測(cè)試用例是相當(dāng)簡(jiǎn)單的，但當(dāng)它每次運(yùn)行時(shí)，一個(gè)臨時(shí)文件被創(chuàng)建然后被刪除。此外，我們沒有辦法去測(cè)試我們的rm方法是否傳遞參數(shù)到os.remove中。我們可以假設(shè)它是基于上面的測(cè)試，但仍有許多需要被證實(shí)。
重構(gòu)與模擬測(cè)試
讓我們使用mock重構(gòu)我們的測(cè)試用例：
#!/usr/bin/env python# -*- coding: utf-8 -*-from mymodule import rmimport mockimport unittestclass RmTestCase(unittest.TestCase):
@mock.patch('mymodule.os')
def test_rm(self, mock_os):
rm("any path") # test that rm called os.remove with the right parameters
mock_os.remove.assert_called_with("any path")
對(duì)于這些重構(gòu)，我們已經(jīng)從根本上改變了該測(cè)試的運(yùn)行方式?，F(xiàn)在，我們有一個(gè)內(nèi)部的對(duì)象，讓我們可以使用另一個(gè)功能驗(yàn)證。
潛在的陷阱
第一件要注意的事情就是，我們使用的mock.patch方法的裝飾位于mymodule.os模擬對(duì)象，并注入到我們測(cè)試案例的模擬方法。是模擬os更有意義，還是它在mymodule.os的參考更有意義？
當(dāng)然，當(dāng)Python出現(xiàn)在進(jìn)口和管理模塊時(shí)，用法是非常的靈活。在運(yùn)行時(shí)，該mymodule模塊有自己的os操作系統(tǒng)——被引入到自己的范圍內(nèi)的模塊。因此，如果我們模擬os系統(tǒng)，我們不會(huì)看到模擬測(cè)試在mymodule模塊的影響。
這句話需要深刻的記?。?/p>
如果你需要為myproject.app.MyElaborateClass模擬tempfile模型，你可能需要去模擬myproject.app.tempfile的每個(gè)模塊來保持自己的進(jìn)口。
這就是用陷阱的方式來模擬測(cè)試。
向‘rm'中加入驗(yàn)證
之前定義的 rm 方法相當(dāng)?shù)暮?jiǎn)單 . 在盲目的刪除之前，我們會(huì)拿它來驗(yàn)證一個(gè)路徑是否存在，并驗(yàn)證其是否是一個(gè)文件. 讓我們重構(gòu) rm 使其變得更加聰明:
#!/usr/bin/env python# -*- coding: utf-8 -*-import osimport os.pathdef rm(filename):
if os.path.isfile(filename):
os.remove(filename)
很好. 現(xiàn)在，讓我們調(diào)整我們的測(cè)試用例來保持測(cè)試的覆蓋程度.
#!/usr/bin/env python# -*- coding: utf-8 -*-from mymodule import rmimport mockimport unittestclass RmTestCase(unittest.TestCase):
@mock.patch('mymodule.os.path')
@mock.patch('mymodule.os')
def test_rm(self, mock_os, mock_path):
# set up the mock
mock_path.isfile.return_value = False
rm("any path")
# test that the remove call was NOT called.
self.assertFalse(mock_os.remove.called, "Failed to not remove the file if not present.")
# make the file 'exist'
mock_path.isfile.return_value = True
rm("any path")
mock_os.remove.assert_called_with("any path")
我們的測(cè)試范例完全變化了. 現(xiàn)在我們可以核實(shí)并驗(yàn)證方法的內(nèi)部功能是否有任何副作用.
將刪除功能作為服務(wù)
到目前為止，我們只是對(duì)函數(shù)功能提供模擬測(cè)試，并沒對(duì)需要傳遞參數(shù)的對(duì)象和實(shí)例的方法進(jìn)行模擬測(cè)試。接下來我們將介紹如何對(duì)對(duì)象的方法進(jìn)行模擬測(cè)試。
首先，我們先將rm方法重構(gòu)成一個(gè)服務(wù)類。實(shí)際上將這樣一個(gè)簡(jiǎn)單的函數(shù)轉(zhuǎn)換成一個(gè)對(duì)象并不需要做太多的調(diào)整，但它能夠幫助我們了解mock的關(guān)鍵概念。下面是重構(gòu)的代碼:
#!/usr/bin/env python# -*- coding: utf-8 -*-import osimport os.pathclass RemovalService(object):
"""A service for removing objects from the filesystem."""
def rm(filename):
if os.path.isfile(filename):
os.remove(filename)
你可以發(fā)現(xiàn)我們的測(cè)試用例實(shí)際上沒有做太多的改變：
#!/usr/bin/env python# -*- coding: utf-8 -*-from mymodule import RemovalServiceimport mockimport unittestclass RemovalServiceTestCase(unittest.TestCase):
@mock.patch('mymodule.os.path')
@mock.patch('mymodule.os')
def test_rm(self, mock_os, mock_path):
# instantiate our service
reference = RemovalService()
# set up the mock
mock_path.isfile.return_value = False
reference.rm("any path")
# test that the remove call was NOT called.
self.assertFalse(mock_os.remove.called, "Failed to not remove the file if not present.")
# make the file 'exist'
mock_path.isfile.return_value = True
reference.rm("any path")
mock_os.remove.assert_called_with("any path")
很好，RemovalService如同我們計(jì)劃的一樣工作。接下來讓我們創(chuàng)建另一個(gè)以該對(duì)象為依賴項(xiàng)的服務(wù):
#!/usr/bin/env python# -*- coding: utf-8 -*-import osimport os.pathclass RemovalService(object):
"""A service for removing objects from the filesystem."""
def rm(filename):
if os.path.isfile(filename):
os.remove(filename)
class UploadService(object):
def __init__(self, removal_service):
self.removal_service = removal_service
def upload_complete(filename):
self.removal_service.rm(filename)
到目前為止，我們的測(cè)試已經(jīng)覆蓋了RemovalService， 我們不會(huì)對(duì)我們測(cè)試用例中UploadService的內(nèi)部函數(shù)rm進(jìn)行驗(yàn)證。相反，我們將調(diào)用UploadService的RemovalService.rm方法來進(jìn)行簡(jiǎn)單的測(cè)試（為了不產(chǎn)生其他副作用），我們通過之前的測(cè)試用例可以知道它可以正確地工作。
有兩種方法可以實(shí)現(xiàn)以上需求:
- 模擬RemovalService.rm方法本身。
- 在UploadService類的構(gòu)造函數(shù)中提供一個(gè)模擬實(shí)例。
因?yàn)檫@兩種方法都是單元測(cè)試中非常重要的方法，所以我們將同時(shí)對(duì)這兩種方法進(jìn)行回顧。
選項(xiàng)1: 模擬實(shí)例的方法
該模擬庫(kù)有一個(gè)特殊的方法用來裝飾模擬對(duì)象實(shí)例的方法和參數(shù)。@mock.patch.object 進(jìn)行裝飾：
#!/usr/bin/env python# -*- coding: utf-8 -*-from mymodule import RemovalService, UploadServiceimport mockimport unittestclass RemovalServiceTestCase(unittest.TestCase):
@mock.patch('mymodule.os.path')
@mock.patch('mymodule.os')
def test_rm(self, mock_os, mock_path):
# instantiate our service
reference = RemovalService()
# set up the mock
mock_path.isfile.return_value = False
reference.rm("any path")
# test that the remove call was NOT called.
self.assertFalse(mock_os.remove.called, "Failed to not remove the file if not present.")
# make the file 'exist'
mock_path.isfile.return_value = True
reference.rm("any path")
mock_os.remove.assert_called_with("any path")
class UploadServiceTestCase(unittest.TestCase):
@mock.patch.object(RemovalService, 'rm')
def test_upload_complete(self, mock_rm):
# build our dependencies
removal_service = RemovalService()
reference = UploadService(removal_service)
# call upload_complete, which should, in turn, call `rm`:
reference.upload_complete("my uploaded file")
# check that it called the rm method of any RemovalService
mock_rm.assert_called_with("my uploaded file")
# check that it called the rm method of _our_ removal_service
removal_service.rm.assert_called_with("my uploaded file")
太棒了！我們驗(yàn)證了上傳服務(wù)成功調(diào)用了實(shí)例的rm方法。你是不是注意到這當(dāng)中有意思的地方了？這種修補(bǔ)機(jī)制實(shí)際上取代了我們的測(cè)試方法的刪除服務(wù)實(shí)例的rm方法。這意味著，我們實(shí)際上可以檢查該實(shí)例本身。如果你想了解更多，可以試著在模擬測(cè)試的代碼中下斷點(diǎn)來更好的認(rèn)識(shí)這種修補(bǔ)機(jī)制是如何工作的。
陷阱：裝飾的順序
當(dāng)使用多個(gè)裝飾方法來裝飾測(cè)試方法的時(shí)候，裝飾的順序很重要，但很容易混亂?；旧?，當(dāng)裝飾方法唄映射到帶參數(shù)的測(cè)試方法中時(shí)，裝飾方法的工作順序是反向的。比如下面這個(gè)例子：
@mock.patch('mymodule.sys')
@mock.patch('mymodule.os')
@mock.patch('mymodule.os.path')
def test_something(self, mock_os_path, mock_os, mock_sys):
pass
注意到了嗎，我們的裝飾方法的參數(shù)是反向匹配的？ 這是有部分原因是因?yàn)?a target="_blank" >Python的工作方式。下面是使用多個(gè)裝飾方法的時(shí)候，實(shí)際的代碼執(zhí)行順序：
patch_sys(patch_os(patch_os_path(test_something)))
由于這個(gè)關(guān)于sys的補(bǔ)丁在最外層，因此會(huì)在最后被執(zhí)行，使得它成為實(shí)際測(cè)試方法的最后一個(gè)參數(shù)。請(qǐng)?zhí)貏e注意這一點(diǎn)，并且在做測(cè)試使用調(diào)試器來保證正確的參數(shù)按照正確的順序被注入。
選項(xiàng)2: 創(chuàng)建模擬測(cè)試接口
我們可以在UploadService的構(gòu)造函數(shù)中提供一個(gè)模擬測(cè)試實(shí)例，而不是模擬創(chuàng)建具體的模擬測(cè)試方法。 我推薦使用選項(xiàng)1的方法，因?yàn)樗_，但在多數(shù)情況下，選項(xiàng)2是必要的并且更加有效。讓我們?cè)俅沃貥?gòu)我們的測(cè)試實(shí)例：
#!/usr/bin/env python# -*- coding: utf-8 -*-from mymodule import RemovalService, UploadServiceimport mockimport unittestclass RemovalServiceTestCase(unittest.TestCase):
@mock.patch('mymodule.os.path')
@mock.patch('mymodule.os')
def test_rm(self, mock_os, mock_path):
# instantiate our service
reference = RemovalService()
# set up the mock
mock_path.isfile.return_value = False
reference.rm("any path")
# test that the remove call was NOT called.
self.assertFalse(mock_os.remove.called, "Failed to not remove the file if not present.")
# make the file 'exist'
mock_path.isfile.return_value = True
reference.rm("any path")
mock_os.remove.assert_called_with("any path")
class UploadServiceTestCase(unittest.TestCase):
def test_upload_complete(self, mock_rm):
# build our dependencies
mock_removal_service = mock.create_autospec(RemovalService)
reference = UploadService(mock_removal_service)
# call upload_complete, which should, in turn, call `rm`:
reference.upload_complete("my uploaded file")
# test that it called the rm method
mock_removal_service.rm.assert_called_with("my uploaded file")
在這個(gè)例子中，我們甚至不需要補(bǔ)充任何功能，只需創(chuàng)建一個(gè)帶auto-spec方法的RemovalService類，然后將該實(shí)例注入到UploadService中對(duì)方法驗(yàn)證。
mock.create_autospec為類提供了一個(gè)同等功能實(shí)例。這意味著，實(shí)際上來說，在使用返回的實(shí)例進(jìn)行交互的時(shí)候，如果使用了非法的方法將會(huì)引發(fā)異常。更具體地說，如果一個(gè)方法被調(diào)用時(shí)的參數(shù)數(shù)目不正確，將引發(fā)一個(gè)異常。這對(duì)于重構(gòu)來說是非常重要。當(dāng)一個(gè)庫(kù)發(fā)生變化的時(shí)候，中斷測(cè)試正是所期望的。如果不使用auto-spec，即使底層的實(shí)現(xiàn)已經(jīng)破壞，我們的測(cè)試仍然會(huì)通過。
陷阱：mock.Mock和mock.MagicMock類
mock庫(kù)包含兩個(gè)重要的類mock.Mock和mock.MagicMock，大多數(shù)內(nèi)部函數(shù)都是建立在這兩個(gè)類之上的。在選擇使用mock.Mock實(shí)例，mock.MagicMock實(shí)例或auto-spec方法的時(shí)候,通常傾向于選擇使用 auto-spec方法，因?yàn)樗軌驅(qū)ξ磥淼淖兓３譁y(cè)試的合理性。這是因?yàn)閙ock.Mock和mock.MagicMock會(huì)無視底層的API，接受所有的方法調(diào)用和參數(shù)賦值。比如下面這個(gè)用例：
class Target(object):
def apply(value):
return valuedef method(target, value):
return target.apply(value)
我們像下面這樣使用mock.Mock實(shí)例來做測(cè)試：
class MethodTestCase(unittest.TestCase):
def test_method(self):
target = mock.Mock()
method(target, "value")
target.apply.assert_called_with("value")
這個(gè)邏輯看似合理，但如果我們修改Target.apply方法接受更多參數(shù)：
class Target(object):
def apply(value, are_you_sure):
if are_you_sure: return value else: return None
重新運(yùn)行你的測(cè)試，然后你會(huì)發(fā)現(xiàn)它仍然能夠通過。這是因?yàn)樗皇轻槍?duì)你的API創(chuàng)建的。這就是為什么你總是應(yīng)該使用create_autospec方法，并且在使用@patch和@patch.object裝飾方法時(shí)使用autospec參數(shù)。
真實(shí)世界的例子: 模仿一次 Facebook API 調(diào)用
在結(jié)束之際，讓我寫一個(gè)更加實(shí)用的真實(shí)世界的例子, 這在我們的介紹部分曾今提到過: 向Facebook發(fā)送一個(gè)消息. 我們會(huì)寫一個(gè)漂亮的封裝類，和一個(gè)產(chǎn)生回應(yīng)的測(cè)試用例.
import facebookclass SimpleFacebook(object):
def __init__(self, oauth_token):
self.graph = facebook.GraphAPI(oauth_token) def post_message(self, message):
"""Posts a message to the Facebook wall."""
self.graph.put_object("me", "feed", message=message)
下面是我們的測(cè)試用例, 它檢查到我發(fā)送了信息，但并沒有實(shí)際的發(fā)送出這條信息（到Facebook上）:
import facebookimport simple_facebookimport mockimport unittestclass SimpleFacebookTestCase(unittest.TestCase):
@mock.patch.object(facebook.GraphAPI, 'put_object', autospec=True)
def test_post_message(self, mock_put_object):
sf = simple_facebook.SimpleFacebook("fake oauth token")
sf.post_message("Hello World!") # verify
mock_put_object.assert_called_with(message="Hello World!")
就我們目前所看到的，在Python中用 mock 開始編寫更加聰明的測(cè)試是真的很簡(jiǎn)單的.
總結(jié)
Python的 mock 庫(kù), 使用起來是有點(diǎn)子迷惑, 是單元測(cè)試的游戲規(guī)則變革者. 我們通過開始在單元測(cè)試中使用 mock ，展示了一些通常的使用場(chǎng)景, 希望這篇文章能幫助 Python 克服一開始的障礙，寫出優(yōu)秀的，能經(jīng)得起測(cè)試的代碼.
相關(guān)文章
基于Python編寫將文本轉(zhuǎn)換為語音的簡(jiǎn)易應(yīng)用
這篇文章主要介紹了如何使用Python編寫一個(gè)簡(jiǎn)單的應(yīng)用程序，將文本轉(zhuǎn)換為語音，文中的示例代碼講解詳細(xì)，感興趣的小伙伴可以動(dòng)手嘗試一下2023-08-08
python 操作mysql數(shù)據(jù)中fetchone()和fetchall()方式
這篇文章主要介紹了python 操作mysql數(shù)據(jù)中fetchone()和fetchall()方式，具有很好的參考價(jià)值，希望對(duì)大家有所幫助。一起跟隨小編過來看看吧2020-05-05
Python&Matlab實(shí)現(xiàn)櫻花的繪制
正值櫻花飄落的季節(jié)，本文將利用Python和Matlab分別繪制一顆櫻花樹，文中的示例代碼講解詳細(xì)，感興趣的小伙伴快跟隨小編一起動(dòng)手嘗試一下2022-04-04
對(duì)Python _取log的幾種方式小結(jié)
今天小編就為大家分享一篇對(duì)Python _取log的幾種方式小結(jié)，具有很好的參考價(jià)值，希望對(duì)大家有所幫助。一起跟隨小編過來看看吧2019-07-07
本文主要介紹了深入理解Django的信號(hào)機(jī)制，文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2023-02-02
這篇文章主要給大家介紹了關(guān)于Python代碼縮進(jìn)和測(cè)試模塊的相關(guān)資料，文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2018-05-05
這篇文章主要為大家詳細(xì)介紹了基于python生成器封裝的協(xié)程類，具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下2019-03-03
這篇文章主要為大家詳細(xì)介紹了python素?cái)?shù)篩選法的相關(guān)資料，具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下2018-03-03
這篇文章主要介紹了Python中Json使用,主要介紹一下python?中?json的使用?如何把dict轉(zhuǎn)成json?、object?轉(zhuǎn)成json?、以及json轉(zhuǎn)成對(duì)象，需要的朋友可以參考下2022-07-07
使用Python的Supervisor進(jìn)行進(jìn)程監(jiān)控以及自動(dòng)啟動(dòng)
這篇文章主要介紹了使用Python的Supervisor進(jìn)行進(jìn)程監(jiān)控以及自動(dòng)啟動(dòng),使用python supervisor實(shí)現(xiàn),需要的朋友可以參考下2014-05-05