2. 程式人生 > >Mock在Python單元測試中的使用

Mock在Python單元測試中的使用

阿新 • • 發佈：2018-12-27

本文講述的是 Python 中 Mock 的使用。

如何執行單元測試而不用考驗你的耐心

很多時候，我們編寫的軟體會直接與那些被標記為“垃圾”的服務互動。用外行人的話說：服務對我們的應用程式很重要，但是我們想要的是互動，而不是那些不想要的副作用，這裡的“不想要”是在自動化測試執行的語境中說的。例如：我們正在寫一個社交 app，並且想要測試一下 “釋出到 Facebook” 的新功能，但是不想每次執行測試集的時候真的釋出到 Facebook。

Python 的 unittest 庫包含了一個名為 unittest.mock 或者可以稱之為依賴的子包，簡稱為 mock —— 其提供了極其強大和有用的方法，通過它們可以模擬mock

並去除那些我們不希望的副作用。

Python

注意：mock最近被收錄[1]到了Python3.3的標準庫中；先前釋出的版本必須通過PyPI[2]下載Mock庫。

恐懼系統呼叫

再舉另一個例子，我們在接下來的部分都會用到它，這是就是系統呼叫。不難發現，這些系統呼叫都是主要的模擬物件：無論你是正在寫一個可以彈出 CD 驅動器的指令碼，還是一個用來刪除 /tmp 下過期的快取檔案的 Web 服務，或者一個繫結到 TCP 埠的 socket 伺服器，這些呼叫都是在你的單元測試上下文中不希望產生的副作用。

作為一個開發者，你需要更關心你的庫是否成功地呼叫了一個可以彈出 CD 的系統函式（使用了正確的引數等等），而不是切身經歷 CD 托盤每次在測試執行的時候都打開了。（或者更糟糕的是，彈出了很多次，在一個單元測試執行期間多個測試都引用了彈出程式碼！）

同樣，保持單元測試的效率和效能意味著需要讓如此多的“緩慢程式碼”遠離自動測試，比如檔案系統和網路訪問。

對於第一個例子來說，我們要從原始形式換成使用 mock 重構一個標準 Python 測試用例。我們會演示如何使用 mock 寫一個測試用例，使我們的測試更加智慧、快速，並展示更多關於我們軟體的工作原理。

一個簡單的刪除函式

我們都有過需要從檔案系統中一遍又一遍的刪除檔案的時候，因此，讓我們在 Python 中寫一個可以使我們的指令碼更加輕易完成此功能的函式。

  1. #!/usr/bin/env python
  2. # -*- coding: utf-8 -*-
  3. import os
  4. def rm(filename
    ):
  5.    os.remove(filename)

很明顯，我們的 rm 方法此時無法提供比 os.remove 方法更多的相關功能，但我們可以在這裡新增更多的功能，使我們的基礎程式碼逐步改善。

讓我們寫一個傳統的測試用例，即，沒有使用 mock：

  1. #!/usr/bin/env python
  2. # -*- coding: utf-8 -*-
  3. from mymodule import rm
  4. import os.path
  5. import tempfile
  6. import unittest
  7. class RmTestCase(unittest.TestCase):
  8.    tmpfilepath = os.path.join(tempfile.gettempdir(), "tmp-testfile")
  9. def setUp(self):
  10. with open(self.tmpfilepath, "wb") as f:
  11.            f.write("Delete me!")
  12. def test_rm(self):
  13. # remove the file
  14. rm(self.tmpfilepath)
  15. # test that it was actually removed
  16. self.assertFalse(os.path.isfile(self.tmpfilepath), "Failed to remove the file.")

我們的測試用例相當簡單，但是在它每次執行的時候，它都會建立一個臨時檔案並且隨後刪除。此外，我們沒有辦法測試我們的 rm 方法是否正確地將我們的引數向下傳遞給 os.remove 呼叫。我們可以基於以上的測試認為它做到了，但還有很多需要改進的地方。

使用 Mock 重構

讓我們使用 mock 重構我們的測試用例：

  1. #!/usr/bin/env python
  2. # -*- coding: utf-8 -*-
  3. from mymodule import rm
  4. import mock
  5. import unittest
  6. class RmTestCase(unittest.TestCase):
  7. @mock.patch('mymodule.os')
  8. def test_rm(self, mock_os):
  9. rm("any path")
  10. # test that rm called os.remove with the right parameters
  11.        mock_os.remove.assert_called_with("any path")

使用這些重構，我們從根本上改變了測試用例的操作方式。現在，我們有一個可以用於驗證其他功能的內部物件。

潛在陷阱

第一件需要注意的事情就是，我們使用了 mock.patch 方法裝飾器，用於模擬位於 mymodule.os 的物件，並且將 mock 注入到我們的測試用例方法。那麼只是模擬 os 本身，而不是 mymodule.os 下 os 的引用（LCTT 譯註：注意 @mock.patch('mymodule.os') 便是模擬 mymodule.os 下的 os），會不會更有意義呢？

當然，當涉及到匯入和管理模組，Python 的用法就像蛇一樣靈活。在執行時，mymodule 模組有它自己的被匯入到本模組區域性作用域的 os。因此，如果我們模擬 os，我們是看不到 mock 在 mymodule 模組中的模仿作用的。

這句話需要深刻地記住：

模擬一個東西要看它用在何處，而不是來自哪裡。

如果你需要為 myproject.app.MyElaborateClass 模擬 tempfile 模組，你可能需要將 mock 用於myproject.app.tempfile，而其他模組保持自己的匯入。

先將那個陷阱放一邊，讓我們繼續模擬。

向 ‘rm’ 中加入驗證

之前定義的 rm 方法相當的簡單。在盲目地刪除之前，我們傾向於驗證一個路徑是否存在，並驗證其是否是一個檔案。讓我們重構 rm 使其變得更加智慧：

  1. #!/usr/bin/env python
  2. # -*- coding: utf-8 -*-
  3. import os
  4. import os.path
  5. def rm(filename):
  6. if os.path.isfile(filename):
  7.        os.remove(filename)

很好。現在，讓我們調整測試用例來保持測試的覆蓋率。

  1. #!/usr/bin/env python
  2. # -*- coding: utf-8 -*-
  3. from mymodule import rm
  4. import mock
  5. import unittest
  6. class RmTestCase(unittest.TestCase):
  7. @mock.patch('mymodule.os.path')
  8. @mock.patch('mymodule.os')
  9. def test_rm(self, mock_os, mock_path):
  10. # set up the mock
  11.        mock_path.isfile.return_value = False
  12. rm("any path")
  13. # test that the remove call was NOT called.
  14. self.assertFalse(mock_os.remove.called, "Failed to not remove the file if not present.")
  15. # make the file 'exist'
  16.        mock_path.isfile.return_value = True
  17. rm("any path")
  18.        mock_os.remove.assert_called_with("any path")

我們的測試用例完全改變了。現在我們可以在沒有任何副作用的情況下核實並驗證方法的內部功能。

將檔案刪除作為服務

到目前為止，我們只是將 mock 應用在函式上，並沒應用在需要傳遞引數的物件和例項的方法上。我們現在開始涵蓋物件的方法。

首先，我們將 rm 方法重構成一個服務類。實際上將這樣一個簡單的函式轉換成一個物件，在本質上這不是一個合理的需求，但它能夠幫助我們瞭解 mock 的關鍵概念。讓我們開始重構：

  1. #!/usr/bin/env python
  2. # -*- coding: utf-8 -*-
  3. import os
  4. import os.path
  5. class RemovalService(object):
  6. """A service for removing objects from the filesystem."""
  7. def rm(filename):
  8. if os.path.isfile(filename):
  9.            os.remove(filename)

你會注意到我們的測試用例沒有太大變化：

  1. #!/usr/bin/env python
  2. # -*- coding: utf-8 -*-
  3. from mymodule import RemovalService
  4. import mock
  5. import unittest
  6. class RemovalServiceTestCase(unittest.TestCase):
  7. @mock.patch('mymodule.os.path')
  8. @mock.patch('mymodule.os')
  9. def test_rm(self, mock_os, mock_path):
  10. # instantiate our service
  11.        reference = RemovalService()
  12. # set up the mock
  13.        mock_path.isfile.return_value = False
  14.        reference.rm("any path")
  15. # test that the remove call was NOT called.
  16. self.assertFalse(mock_os.remove.called, "Failed to not remove the file if not present.")
  17. # make the file 'exist'
  18.        mock_path.isfile.return_value = True
  19.        reference.rm("any path")
  20.        mock_os.remove.assert_called_with("any path")

很好，我們知道 RemovalService 會如預期般的工作。接下來讓我們建立另一個服務，將 RemovalService 宣告為它的一個依賴：

  1. #!/usr/bin/env python
  2. # -*- coding: utf-8 -*-
  3. import os
  4. import os.path
  5. class RemovalService(object):
  6. """A service for removing objects from the filesystem."""
  7. def rm(self, filename):
  8. if os.path.isfile(filename):
  9.            os.remove(filename)
  10. class UploadService(object):
  11. def __init__(self, removal_service):
  12. self.removal_service = removal_service
  13. def upload_complete(self, filename):
  14. self.removal_service.rm(filename)

因為我們的測試覆蓋了 RemovalService，因此我們不會對我們測試用例中 UploadService 的內部函式 rm 進行驗證。相反，我們將呼叫 UploadService 的 RemovalService.rm 方法來進行簡單測試（當然沒有其他副作用），我們通過之前的測試用例便能知道它可以正確地工作。

這裡有兩種方法來實現測試：

  1. 模擬 RemovalService.rm 方法本身。
  2. 在 UploadService 的建構函式中提供一個模擬例項。

因為這兩種方法都是單元測試中非常重要的方法，所以我們將同時對這兩種方法進行回顧。

方法 1：模擬例項的方法

mock 庫有一個特殊的方法裝飾器，可以模擬物件例項的方法和屬性，即 @mock.patch.object decorator 裝飾器：

  1. #!/usr/bin/env python
  2. # -*- coding: utf-8 -*-
  3. from mymodule import RemovalService, UploadService
  4. import mock
  5. import unittest
  6. class RemovalServiceTestCase(unittest.TestCase):
  7. @mock.patch('mymodule.os.path')
  8. @mock.patch('mymodule.os')
  9. def test_rm(self, mock_os, mock_path):
  10. # instantiate our service
  11.        reference = RemovalService()
  12. # set up the mock
  13.        mock_path.isfile.return_value = False
  14.        reference.rm("any path")
  15. # test that the remove call was NOT called.
  16. self.assertFalse(mock_os.remove.called, "Failed to not remove the file if not present.")
  17. # make the file 'exist'
  18.        mock_path.isfile.return_value = True
  19.        reference.rm("any path")
  20.        mock_os.remove.assert_called_with("any path")
  21. class UploadServiceTestCase(unittest.TestCase):
  22. @mock.patch.object(RemovalService, 'rm')
  23. def test_upload_complete(self, mock_rm):
  24. # build our dependencies
  25.        removal_service = RemovalService()
  26.        reference = UploadService(removal_service)
  27. # call upload_complete, which should, in turn, call `rm`:
  28.        reference.upload_complete("my uploaded file")
  29. # check that it called the rm method of any RemovalService
  30.        mock_rm.assert_called_with("my uploaded file")
  31. # check that it called the rm method of _our_ removal_service
  32.        removal_service.rm.assert_called_with("my uploaded file")

非常棒！我們驗證了 UploadService 成功呼叫了我們例項的 rm 方法。你是否注意到一些有趣的地方？這種修補機制（patching mechanism）實際上替換了我們測試用例中的所有 RemovalService 例項的 rm 方法。這意味著我們可以檢查例項本身。如果你想要了解更多，可以試著在你模擬的程式碼下斷點，以對這種修補機制的原理獲得更好的認識。

陷阱：裝飾順序

當我們在測試方法中使用多個裝飾器，其順序是很重要的，並且很容易混亂。基本上，當裝飾器被對映到方法引數時，裝飾器的工作順序是反向的[3]。思考這個例子：

  1. @mock.patch('mymodule.sys')
  2. @mock.patch('mymodule.os')
  3. @mock.patch('mymodule.os.path')
  4. def test_something(self, mock_os_path, mock_os, mock_sys):
  5. pass

注意到我們的引數和裝飾器的順序是反向匹配了嗎？這部分是由 Python 的工作方式[4]所導致的。這裡是使用多個裝飾器的情況下它們執行順序的虛擬碼：

  1. patch_sys(patch_os(patch_os_path(test_something)))

因為 sys 補丁位於最外層，所以它最晚執行，使得它成為實際測試方法引數的最後一個引數。請特別注意這一點，並且在執行你的測試用例時，使用偵錯程式來保證正確的引數以正確的順序注入。

方法 2：建立 Mock 例項

我們可以使用建構函式為 UploadService 提供一個 Mock 例項，而不是模擬特定的例項方法。我更推薦方法 1，因為它更加精確，但在多數情況，方法 2 或許更加有效和必要。讓我們再次重構測試用例：

  1. #!/usr/bin/env python
  2. # -*- coding: utf-8 -*-
  3. from mymodule import RemovalService, UploadService
  4. import mock
  5. import unittest
  6. class RemovalServiceTestCase(unittest.TestCase):
  7. @mock.patch('mymodule.os.path')
  8. @mock.patch('mymodule.os')
  9. def test_rm(self, mock_os, mock_path):
  10. # instantiate our service
  11.        reference = RemovalService()
  12. # set up the mock
  13.        mock_path.isfile.return_value = False
  14.        reference.rm("any path")
  15. # test that the remove call was NOT called.
  16. self.assertFalse(mock_os.remove.called, "Failed to not remove the file if not present.")
  17. # make the file 'exist'
  18.        mock_path.isfile.return_value = True
  19.        reference.rm("any path")
  20.        mock_os.remove.assert_called_with("any path")
  21. class UploadServiceTestCase(unittest.TestCase):
  22. def test_upload_complete(self, mock_rm):
  23. # build our dependencies
  24.        mock_removal_service = mock.create_autospec(RemovalService)
  25.        reference = UploadService(mock_removal_service)
  26. # call upload_complete, which should, in turn, call `rm`:
  27.        reference.upload_complete("my uploaded file")
  28. # test that it called the rm method
  29.        mock_removal_service.rm.assert_called_with("my uploaded file")

在這個例子中，我們甚至不需要修補任何功能，只需為 RemovalService 類建立一個 auto-spec，然後將例項注入到我們的 UploadService 以驗證功能。

mock.create_autospec 方法為類提供了一個同等功能例項。實際上來說，這意味著在使用返回的例項進行互動的時候，如果使用了非法的方式將會引發異常。更具體地說，如果一個方法被呼叫時的引數數目不正確，將引發一個異常。這對於重構來說是非常重要。當一個庫發生變化的時候，中斷測試正是所期望的。如果不使用 auto-spec，儘管底層的實現已經被破壞，我們的測試仍然會通過。

陷阱：mock.Mock 和 mock.MagicMock 類

mock 庫包含了兩個重要的類 mock.Mock[5] 和 mock.MagicMock[6]，大多數內部函式都是建立在這兩個類之上的。當在選擇使用 mock.Mock 例項、mock.MagicMock 例項還是 auto-spec 的時候，通常傾向於選擇使用 auto-spec，因為對於未來的變化，它更能保持測試的健全。這是因為 mock.Mock 和 mock.MagicMock 會無視底層的 API，接受所有的方法呼叫和屬性賦值。比如下面這個用例：

  1. class Target(object):
  2. def apply(value):
  3. return value
  4. def method(target, value):
  5. return target.apply(value)

我們可以像下面這樣使用 mock.Mock 例項進行測試：

  1. class MethodTestCase(unittest.TestCase):
  2. def test_method(self):
  3.        target = mock.Mock()
  4.        method(target, "value")
  5.        target.apply.assert_called_with("value")

這個邏輯看似合理，但如果我們修改 Target.apply 方法接受更多引數：

  1. class Target(object):
  2. def apply(value, are_you_sure):
  3. if are_you_sure:
  4. return value
  5. else:
  6. return None

重新執行你的測試，你會發現它仍能通過。這是因為它不是針對你的 API 建立的。這就是為什麼你總是應該使用create_autospec 方法，並且在使用 @patch和 @patch.object 裝飾方法時使用 autospec 引數。

現例項子：模擬 Facebook API 呼叫

作為這篇文章的結束，我們寫一個更加適用的現例項子，一個在介紹中提及的功能：釋出訊息到 Facebook。我將寫一個不錯的包裝類及其對應的測試用例。

  1. import facebook
  2. class SimpleFacebook(object):
  3. def __init__(self, oauth_token):
  4. self.graph = facebook.GraphAPI(oauth_token)
  5. def post_message(self, message):
  6. """Posts a message to the Facebook wall."""
  7. self.graph.put_object("me", "feed", message=message)

這是我們的測試用例，它可以檢查我們釋出的訊息,而不是真正地釋出訊息：

  1. import facebook
  2. import simple_facebook
  3. import mock
  4. import unittest
  5. class SimpleFacebookTestCase(unittest.TestCase):
  6. @mock.patch.object(facebook.GraphAPI, 'put_object', autospec=True)
  7. def test_post_message(self, mock_put_object):
  8.        sf = simple_facebook.SimpleFacebook("fake oauth token")
  9.        sf.post_message("Hello World!")
  10. # verify
  11.        mock_put_object.assert_called_with(message="Hello World!")

正如我們所看到的，在 Python 中，通過 mock，我們可以非常容易地動手寫一個更加智慧的測試用例。

Python Mock 總結

即使對它的使用還有點不太熟悉，對單元測試[7]來說，Python的mock庫可以說是一個規則改變者。我們已經演示了常見的用例來了解了mock在單元測試中的使用，希望這篇文章能夠幫助Python開發者[8]克服初期的障礙，寫出優秀、經受過考驗的程式碼。

via:https://www.toptal.com/python/an-introduction-to-mocking-in-python

作者：NAFTULITZVIKAY[9]譯者：cposture[10]校對：wxy[11]

本文由LCTT[12]原創翻譯，Linux中國[13]榮譽推出

[1]: http://www.python.org/dev/peps/pep-0417/
[2]: https://pypi.python.org/pypi/mock
[3]: http://www.voidspace.org.uk/python/mock/patch.html#nesting-patch-decorators
[4]: http://docs.python.org/2/reference/compound_stmts.html#function-definitions
[5]: http://www.voidspace.org.uk/python/mock/mock.html
[6]: http://www.voidspace.org.uk/python/mock/magicmock.html#magic-mock
[7]: http://www.toptal.com/qa/how-to-write-testable-code-and-why-it-matters
[8]: http://www.toptal.com/python
[9]: http://www.slviki.com/
[10]: https://github.com/cposture
[11]: https://github.com/wxy
[12]: https://github.com/LCTT/TranslateProject
[13]: https://linux.cn/

推薦閱讀

相關推薦

java~springboot~h2數據庫在單元測試中的使用

存儲 會同 oot 直接 context user get pil runner 單元測試有幾點要說的 事實上springboot框架是一個tdd框架，你在進行建立項目時它會同時建立一個單元測試項目，而我們的代碼用例可以在這個項目裏完成，對於單元測試大叔有以下幾點需要說明一

SSM專案 單元測試中 注入bean 空指標異常

java.lang.NullPointerException at com.cumt.service.ShopCategoryServiceTest.testGetShopCategoryList(ShopCategoryServiceTest.java:22) at sun.reflect.NativeMe

在單元測試中處理Debug.Assert的好方法

在單元測試專案的配置檔案中配置好， <?xml version="1.0" encoding="utf-8"?> <configuration> <system.diagnostics> <assert assertuienabled="false"/

單元測試中測試用例的設計方法

單元測試中測試用例的設計方法 1. 用於語句覆蓋的基路徑法 基路徑法保證設計出的測試用例，使程式的每一個可執行語句至少執行一次，即實現語句覆蓋。基路徑法是理論與應用脫節的典型，基本上沒有應用價值，讀者稍作了解即可，不必理解和掌握。 基路徑法步驟如下： 1）畫出程式的控制流圖 控制

Mock在Python單元測試中的使用

本文講述的是 Python 中 Mock 的使用。 如何執行單元測試而不用考驗你的耐心 很多時候，我們編寫的軟體會直接與那些被標記為“垃圾”的服務互動。用外行人的話說：服務對我們的應用程式很重要，但是我們想要的是互動，而不是那些不想要的副作用，這裡的“不想要”是在自動化測試執行的語境中說的。例如：我

Android單元測試中AndroidJUnit4獲取context

在AndroidJUnit4直接通過getContext()獲取到的context並不是當前APP的context，而是instrumentation的context，應使用以下方法來獲取context。 InstrumentationRegistry.getInstrum

Moq 在.net Core 單元測試中的使用

Moq,主要用來偽造介面的實現類,實現方法,屬性 moq The most popular and friendly mocking framework for .NET What? Moq (pronounced "Mock-you" or just "Mock") is the onl

在JUnit單元測試中獲取bean

一、使用註解@Autowired注入bean package test; import java.util.List; import org.junit.Test; import org.juni

認識單元測試中的打樁

        什麼是樁        樁，或稱樁程式碼，是指用來代替關聯程式碼或者未實現程式碼的程式碼。如果函式B用B1來代替，那麼，B稱為原函式，B1稱為樁函式。打樁就是編寫或生成樁程式碼。        打樁的目的        打樁的目的主要有：隔離、補齊、控制

Java後臺框架篇--Spring單元測試中的H2資料庫

H2資料庫是一種由Java編寫的，極小，速度極快，可嵌入式的資料庫。非常適合用在單元測試等資料不需要儲存的場景下面。 以下時其官網的介紹： {% blockquote h2 http://www.h2database.com/html/main.html h2 %}Wel

關於junit單元測試中的注入錯誤

之前寫的一個專案，在做單元測試的時候，用了service來儲存資料，然後就發現了一個錯誤：spring的注入錯誤，我在service類上加了component並且在spring的component-scan也配置了相應的路徑，要注入的東西也都加了@Resource，在測試

JUnit單元測試中的setUpBeforeClass()、tearDownAfterClass()、setUp()、tearDown()方法小結

編寫JUnit單元測試的時候，會用到setUpBeforeClass()、tearDownAfterClass()、setUp()、tearDown()這四個方法，例如用eclipse新建一個junit test case的時候，就會有如下圖1的視窗讓你去選擇使用哪些方

.NET2005下單元測試中Assert類的用法。

{            System.IO.FileInfo file =null;            System.IO.FileInfo file1 = file;            System.IO.DirectoryInfo dir =null;            string tem

【解決】Junit單元測試中出現的報錯

at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) at java.lang.ClassLoader.de

Jquery/js單元測試中實現Mock（js實現mock介面）

<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Title</title> <script type="text/

java單元測試中setUp方法和setUpBeforeClass方法的區別

今天寫了一個類，向檔案中寫入內容。但是單元測試時，檢視檔案，發現要寫的內容在檔案中總是重複好幾次。而且重複的次數正好和要測試的方法的次數相等。就想到問題出在setUp方法上，google了一下，發現setUp方法原來是

【java】單元測試中修改系統時間

參考文章： Java8的DateTimeFormatter是執行緒安全的，而SimpleDateFormat並不是執行緒安全 import java.time.Clock; import java.time.LocalDateTime; import

Java 單元測試中的多執行緒無故退出

原文：https://my.oschina.net/heweipo/blog/497176 問題發現 最近在複習多執行緒相關知識，結果一動手就出現了問題，問題是這樣的，在單元測試中使用多執行緒測試，發現只要子執行緒在睡眠一段時間，程式就退出了，毫無徵兆！！！！ 看看

單元測試中mock的使用及mock神器jmockit實踐

在最近的r應用的單元測試中，經常需要用到mock，可以說mock在ut （unit test）中是無處不在的。而在r的ut實踐中也找到了一種很簡潔的mock方式，不僅解決了ut中所有需要mock的地方，而且可以很少量的程式碼來完成mock。詳見下文。 　　一.Mock

.NET Core之單元測試（二）：使用記憶體資料庫處理單元測試中的資料庫依賴

目錄 定義一個待測試API 測試用例 為減少篇幅，隱藏了SampleEntity和SqliteDbContext 定義一個待測試API 如下，我們定義了一個名為Sample的API，其中有一個外部依賴項Sqli