Linux中國

Mock 在 Python 單元測試中的使用

259 views0
By
Share

注意：mock 最近被收錄到了 Python 3.3 的標準庫中；先前發布的版本必須通過 PyPI 下載 Mock 庫。

恐懼系統調用

再舉另一個例子，我們在接下來的部分都會用到它，這是就是系統調用。不難發現，這些系統調用都是主要的模擬對象：無論你是正在寫一個可以彈出 CD 驅動器的腳本，還是一個用來刪除 /tmp 下過期的緩存文件的 Web 服務，或者一個綁定到 TCP 埠的 socket 伺服器，這些調用都是在你的單元測試上下文中不希望產生的副作用。

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

同樣，保持單元測試的效率和性能意味著需要讓如此多的「緩慢代碼」遠離自動測試，比如文件系統和網路訪問。

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

一個簡單的刪除函數

我們都有過需要從文件系統中一遍又一遍的刪除文件的時候，因此，讓我們在 Python 中寫一個可以使我們的腳本更加輕易完成此功能的函數。

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import os

def rm(filename):
    os.remove(filename)

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

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

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from mymodule import rm

import os.path
import tempfile
import unittest

class 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.tmpfilepath), "Failed to remove the file.")

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

使用 Mock 重構

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

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from mymodule import rm

import mock
import unittest

class 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")

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

潛在陷阱

第一件需要注意的事情就是，我們使用了 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 使其變得更加智能：

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import os
import os.path

def rm(filename):
    if os.path.isfile(filename):
        os.remove(filename)

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

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from mymodule import rm

import mock
import unittest

class 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")

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

將文件刪除作為服務

到目前為止，我們只是將 mock 應用在函數上，並沒應用在需要傳遞參數的對象和實例的方法上。我們現在開始涵蓋對象的方法。

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

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import os
import os.path

class RemovalService(object):
    """A service for removing objects from the filesystem."""

    def rm(filename):
        if os.path.isfile(filename):
            os.remove(filename)

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

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from mymodule import RemovalService

import mock
import unittest

class 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 會如預期般的工作。接下來讓我們創建另一個服務，將 RemovalService 聲明為它的一個依賴：

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import os
import os.path

class RemovalService(object):
    """A service for removing objects from the filesystem."""

    def rm(self, 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(self, filename):
        self.removal_service.rm(filename)

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

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

  1. 模擬 RemovalService.rm 方法本身。
  2. 在 UploadService 的構造函數中提供一個模擬實例。

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

方法 1：模擬實例的方法

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

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from mymodule import RemovalService, UploadService

import mock
import unittest

class 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")

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

陷阱：裝飾順序

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

    @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

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

patch_sys(patch_os(patch_os_path(test_something)))

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

方法 2：創建 Mock 實例

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

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from mymodule import RemovalService, UploadService

import mock
import unittest

class 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")

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

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

陷阱：mock.Mock 和 mock.MagicMock 類

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

class Target(object):
    def apply(value):
        return value

def method(target, value):
    return target.apply(value)

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

class MethodTestCase(unittest.TestCase):

    def test_method(self):
        target = mock.Mock()

        method(target, "value")

        target.apply.assert_called_with("value")

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

class Target(object):
    def apply(value, are_you_sure):
        if are_you_sure:
            return value
        else:
            return None

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

現實例子：模擬 Facebook API 調用

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

import facebook

class 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)

這是我們的測試用例，它可以檢查我們發布的消息,而不是真正地發布消息：

import facebook
import simple_facebook
import mock
import unittest

class 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，我們可以非常容易地動手寫一個更加智能的測試用例。

Python Mock 總結

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

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

作者：NAFTULI TZVI KAY 譯者：cposture 校對：wxy

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

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive

對這篇文章感覺如何？

太棒了
0
不錯
0
愛死了
0
不太好
0
感覺很糟
0
雨落清風。心向陽
    Previous
    Next

    You may also like

    Leave a reply

    您的郵箱地址不會被公開。 必填項已用 * 標註

    此站點使用Akismet來減少垃圾評論。了解我們如何處理您的評論數據。

    More in:Linux中國