2. 程式人生 > >[OpenStack UT] 分析OpenStack中單元測試之mock & mox

[OpenStack UT] 分析OpenStack中單元測試之mock & mox

阿新 • • 發佈：2019-01-01

在社群貢獻OpenStackcode時，會經常短短的幾行程式碼也要新增不少的UT，耗時耗力，mock & mox 是很好的實現隔離的單元測試模組， 理解它們能夠更快的做UT的編碼。

mock & mox: 

都是python中用於實現單元測試的module庫, 實現的是隔離, 它通過替換測試內容中的一部分(比如class, function等object).  專注在function的核心實現邏輯的測試上. 比如把db操作, I/O, 網路相關操所如socket, ssh等隔離掉, 在測試執行過程中， 當執行到它們時， 不會深入它們方法內部去執行， 而是直接返回我們假設的一個值。

mock的設計與我們知道mox實現框架不一樣, mock是'action->assertion' 方式, mox是典型的'record -> replay->verify'方式, 以例子來分析

mock :

下面這個簡單例子摘在mock原始碼包自帶的使用介紹上

>>> from mock import Mock
>>> real = ProductionClass()
>>> real.method = Mock(return_value=3)
>>> real.method(3, 4, 5, key='value')
3
>>> real.method.assert_called_with(3, 4, 5, key='value')

前四行為action, 最後一行assertion，檢查是否被呼叫, 並且可以同時檢查呼叫的引數是否正確.

mox:

mox 的工作方式可以很清晰的在mox 發行的package中看程式碼，mox.py中可以得到很清晰的理解, 使用一般會經歷三種模式的工作狀態， 具體的測試時，有時第三種模式工作狀態沒有用到。

record mode: 建立一個mock物件, 設定mock物件的期望行為, 如返回的值, 傳入引數及其順序.

replay mode: 這一步開始真正的測試, 執行我們測試的方法

verify mode: 這一步開始校驗我們在recode mode設定的一些行為是否被期望的執行, 執行是否正確.

關於mox建立mock object的使用是非執行緒安全的, 在多執行緒情況下呼叫需要使用互斥鎖.

以下示例摘自mox.py, 簡易清晰的講述了mox工作流程, 3-13行為recode mode, 14-19行為replay mode, 19行之後為verify mode. 當然實際使用過程中很少這樣簡單, 會用到mox中提供的其他功能. 之後會講到。

Suggested usage / workflow:

  # Create Mox factory
  my_mox = Mox()

  # Create a mock data access object
  mock_dao = my_mox.CreateMock(DAOClass)

  # Set up expected behavior
  mock_dao.RetrievePersonWithIdentifier('1').AndReturn(person)
  mock_dao.DeletePerson(person)

  # Put mocks in replay mode
  my_mox.ReplayAll()

  # Inject mock object and run test
  controller.SetDao(mock_dao)
  controller.DeletePersonById('1')

  # Verify all methods were called as expected
  my_mox.VerifyAll()

接下來介紹下OpenStack中關於這兩種python 測試框架的常見使用

1. [mox] StubOutWithMock

在OpenStack的test code中我們經常看到mox中使用StubOutWithMock, 這個function做的事情就是用mock物件替掉一些方法或者屬性. 見下例，摘自OpenStack中程式碼片段，用來說明StubOutWithMock用法。

   self.mox.StubOutWithMock(quota.QUOTAS, "reserve") #quota.QUOTAS.reserve替換為mock物件
   quota.QUOTAS.reserve(self.context, instances=40,cores=mox.IsA(int),ram=mox.IsA(int)
   ).AndRaise(quota_exception) #mox.IsA是測試基本資料或物件型別的
   self.mox.ReplayAll()
   function(...) #這裡簡單化了這個方法, 它是呼叫過quota.QUOTAS.reserve的一個function,
                 #也即是我們需要測試的function

2.[mock] mock.patch & mock.patch.object

  這兩者用於把物件class, function, attribute  做成一個mock.

  從定義上就可以看出兩者之間的差別

   mock.patch(target, ...)

   mock.patch.object(target, attribute, ...)

   前者給target做mock, 這個target可以是class, function

   後者給target上的attribute作mock, 一般使用中用的比較多的是物件上的function. 

具體實現上, 兩者都可以有兩種寫法, 一種叫decorators, 利用python中的裝飾@, 另一種用with語句, 下面是隨便寫的一個例子

隨便定義一個簡單的func()來被測試

class A(object):    
    def func(self):
        return B.getFromDB('b')
        
class B(object):
    def getFromDB(self, param):
        ...

具體的測試方法如下

"""第一種寫法, decorators方式, 採用mock.patch模擬一個方法.
          當有多個方法時注意一點就是引數的順序, 如
   @mock.patch('B.getFromDB')
   @mock.patch('B.getFromXX')
   def test_func(self, mock_getFromXX, mock_getFromDB):
   可以看到後@的物件在引數列表中在前面, 這個是由於@的執行順序為@mock.patch('B.getFromDB')(@mock.patch('B.getFromXX')(func)) 決定的
"""        
@mock.patch('B.getFromDB')
def test_func(self, mock_getFromDB):
    mock_getFromDB.return_value = '1'
    self.assertEqual('1', A.func())

"""第二種寫法 ,decorators方式, 採用mock.patch. object模擬一個方法.
"""   
@mock.patch.object(B, 'getFromDB')
def test_func(self, mock_getFromDB):
    mock_getFromDB.return_value = '1'
    self.assertEqual('1', A.func())

"""第三種寫法, with statement, 採用mock.patch模擬一個方法.
"""   
def test_func(self, mock_getFromDB):
    with mock.patch('B.getFromDB') as mock_getFromDB:
        mock_getFromDB.return_value = '1'
    self.assertEqual('1', A.func())

"""第四種寫法, with statement, 採用mock.patch.object模擬一個方法.
"""   
def test_func(self, mock_getFromDB):
    with mock.patch.object(B, 'getFromDB') as mock_getFromDB:
        mock_getFromDB.return_value = '1'
    self.assertEqual('1', A.func())

上面的例子中, 關於mock.patch模擬的都是function, 沒有針對class, 下面是mock.patch document 給出的例子,

>>> class Class(object):
...     def method(self):
...         pass
...
>>> with patch('__main__.Class') as MockClass:
...     instance = MockClass.return_value #本例中模擬了'__main__.Class'這個class, 現把模擬結果賦給intance來測試
...     instance.method.return_value = 'foo' #模擬物件和原class有相同的atribute, 故模擬物件也由method()函式, 可以模擬其返回值
...     assert Class() is instance
...     assert Class().method() == 'foo'
它模擬class, 在OpneStack各個component中現在用的不多.

3.[mock] side_effect

上面的例子中都是使用模擬物件的return_value, 其實side_effect也經常用, 經常使用它的時候是模擬拋異常 或者模擬一個數據序列.

拋異常

下面是個拋異常的例子 模擬cinder.backup.API的restore方法, 並設定當它被呼叫時, 丟擲異常exception.VolumeSizeExceedsAvailableQuota(requested='2',            consumed='2',quota='3')

    @mock.patch('cinder.backup.API.restore')
    def test_restore_backup_with_VolumeSizeExceedsAvailableQuota(
            self,
            _mock_backup_restore):

        _mock_backup_restore.side_effect = \
            exception.VolumeSizeExceedsAvailableQuota(requested='2',
                                                      consumed='2',
                                                      quota='3')

模擬資料序列,

這種主要用於在一個test裡面, 測試過程中多次呼叫到模擬的物件時, 需要按照呼叫先後順序分別給予不同的返回值的情況, 一個很好的例子, 摘自cinder專案的test_backups.py，用來講述模擬一個數據序列的用法

    """省略了幾個測試用例, 主要講兩個,
       backup_api._is_backup_service_enabled會呼叫cinder.db.service_get_all_by_topic,
       使用side_effect 後, 可以多次測試_is_backup_service_enabled模擬不同情況
       每次_is_backup_service_enabled呼叫到service_get_all_by_topic時, 模擬的返回值為設定的資料列表中的next one.
    """
    @mock.patch('cinder.db.service_get_all_by_topic')
    def test_is_backup_service_enabled(self, _mock_service_get_all_by_topic):

        test_host = 'test_host'
        alt_host = 'strange_host'
        empty_service = []
        #service host not match with volume's host
        host_not_match = [{'availability_zone': "fake_az", 'host': alt_host,
                           'disabled': 0, 'updated_at': timeutils.utcnow()}]
        ...
        #Setup mock to run through the following service cases
        _mock_service_get_all_by_topic.side_effect = [empty_service,
                                                      host_not_match,
                                                      ...]
        volume_id = utils.create_volume(self.context, size=2,host=test_host)['id']
        volume = self.volume_api.get(context.get_admin_context(), volume_id)
        #test empty service
        self.assertEqual(self.backup_api._is_backup_service_enabled(volume, test_host), False)
        #test host not match service
        self.assertEqual(self.backup_api._is_backup_service_enabled(volume, test_host), False)

4.[mock] MagicMock

也可以看到有些地方使用到了MagicMock, 它是Mock的子類, 它首先是實現了Mock的所有功能，它的更好的地方在於它自動實現大部分magic method(這些方法以雙下劃線開頭的， 詳細瞭解見http://www.ironpythoninaction.com/magic-methods.html)的模擬了,省去了我們使用它們時額外需要的設定。比如一些magic method的return value就有預設的值，如下所示，這些摘自mock 自帶的文件中,
    __int__ : 1
    __contains__ : False
    __len__ : 1
    __iter__ : iter([])
    __exit__ : False
    __complex__ : 1j
    __float__ : 1.0
    __bool__ : True
    __nonzero__ : True
    __oct__ : ‘1’
    __hex__ : ‘0x1’
    __long__ : long(1)
    __index__ : 1
    __hash__ : default hash for the mock
    __str__ : default str for the mock
    __unicode__ : default unicode for the mock
    __sizeof__: default sizeof for the mock

相關推薦

[OpenStack UT] 分析OpenStack中單元測試之mock & mox

在社群貢獻OpenStackcode時，會經常短短的幾行程式碼也要新增不少的UT，耗時耗力，mock & mox 是很好的實現隔離的單元測試模組， 理解它們能夠更快的做UT的編碼。 mock & mox:  都是python中用於實現單元測試的module

python筆記24-unittest單元測試之mock.patch

rom Coding int self. 錯誤 測試用例 方法 org auto 前言 上一篇python筆記23-unittest單元測試之mock對mock已經有初步的認識, 本篇繼續介紹mock裏面另一種實現方式，patch裝飾器的使用,patch() 作為函數裝飾器

單元測試之Mock(Moq)

inter 商品 void 簡單 calc 不用 準備 targe ted Mock翻譯為“嘲弄”，其實就是偽造一個對象用於測試。在單元測試中，被測試方法依賴於其他對象時，為了測試簡單一般“偽造”一個這個對象；這樣做的目的： 不用考慮依賴對象的復雜性（方便準備測試數據）

比較完整的junit單元測試之-----mock模擬測試

為什麼需要模擬?  　　在我們一開始學程式設計時，我們所寫的物件通常都是獨立的。hello world之類的類並不依賴其他的類（System.out除外），也不會操作別的類。但實際上軟體中是充滿依賴關係的。我們會基於service類寫操作類，而service類又是基於資料訪問類(DAOs)的，依

python筆記23-unittest單元測試之mock

顯示 現實 name pan blog 我只 服務 接口 模擬 unittest.mock是一個用於在Python中進行單元測試的庫，Mock翻譯過來就是模擬的意思，顧名思義這個庫的主要功能是模擬一些東西。它的主要功能是使用mock對象替代掉指定的Python對象，以達

golang單元測試之mock

搞單元測試，如果碰到這些情況： 1，一個函式，內部包含了很多並且很深的呼叫，但是如果單單測這個函式，其實實現的功能很簡單。 2，一個函式，包含了其他還未實現的呼叫。 3，函式內部對資料的要求極為苛刻。 那麼這時候就可以考慮使用mock來處理。 mock

[OpenStack UT] 單元測試之Monkey Patch

再說monkey patch之前先說下, python中的Test Double, Test Double就是在測試case中給某個物件做替身的意思. 用一個假物件替換. 用Test Double時， 可以有三種實現的形式， Stub，Mock object, Fake O

[OpenStack UT]單元測試之testscenarios

看heat code， 看到testscenarios的使用， 好奇的研究了下 testscenarios 其實實現的就是這樣一種框架，在class中給scenarios賦值，描述出不同場景， 測試case就可以通過testscenarios框架自動生成針對這些scenar

單元測試之Stub和Mock

下載 我們 並且 試用 sample 註入 mes oge new 單元測試之Stub和Mock FROM：http://www.cnblogs.com/TankXiao/archive/2012/03/06/2366073.html 在做單元測試的時候，我們會發現我

Java、JavaWeb中單元測試用到的測試方法

enc nbsp 方法 hat 思維 .com java assert 可能 寫出的代碼做單元測試時，一定要記住從三個方面出發：1、成功 2、異常 3 邏輯錯誤（即沒有異常也可能程序運行出最後結果，可是呢？呵呵）。這就是在做測試時我要牢記的三個方面，同時思維要嚴謹也即做

springboot中單元測試

spring alt logs api bsp log 單元測試 1-1 單元 測試service： 測試api： springboot中單元測試

python + unittest 做單元測試之學習筆記

stl unittest 例子 gin pre log script 有關 assert 單元測試在保證開發效率、可維護性和軟件質量等方面有很重要的地位，所謂的單元測試，就是對一個類，一個模塊或者一個函數進行正確性檢測的一種測試方式。 這裏主要是就應用 python + u

論單元測試之重要性

表單 曾經 mybatis 服務 request 第一個 完成 分離 能說 單元測試的重要性不言而喻，自我開發生涯以來，從很少註釋過過場場，到非常重視。 單元測試為什麽會讓人忽視呢？ 通常情況像一些查詢或者增刪改之類，拿我來說，即便報錯我大概一掃，我就知道錯誤是什麽了，該如

補習系列-springboot 單元測試之道

try 精彩 一次 run rest spec ner hat ltm 目錄 目標 一、About 單元測試 二、About Junit 三、SpringBoot-單元測試 項目依賴 測試樣例 四、Mock測試 五、最後 目標 了解 單元測試的背景 了解如何 利用

python中單元測試的常用語句

單元 ble item resp 測試的 pytho con The ret assertEqual 如果兩個值相等，則passassertNotEqual 如果兩個值不相等，則passassertTrue 判斷bool值為True，則passasser

java單元測試之如何實現非同步介面的測試案例

測試是軟體釋出的重要環節，單元測試在實際開發中是一種常用的測試方法，java單元測試主要用junit，最新是junit5，本人開發一般用junit4。因為單元測試能夠在軟體模組組合之前儘快發現問題，所以實際開發中投入產出比很高。實際使用難免會遇到非同步操作的介面測試，最常用的情景是別人家的SD

前端單元測試之Jest

概述 關於前端單元測試的好處自不必說，基礎的介紹和知識可以參考之前的部落格連結：React Native單元測試。在軟體的測試領域，測試主要分為：單元測試、整合測試和功能測試。 單元測試：在計算機程式設計中，單元測試（英語：Unit Testing）又稱為模組測試, 是針對程式模組（軟體設計的最小單

SSM配置中單元測試註解@Runwith遇到的坑

@Runwith測試單元類報錯，導包無效 @RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(locations ={"classpath:applicationContext.xml"}) public

spring boot單元測試之druid NullPointException

最近在使用spring boot 對 Controller 進行單元測試時，發現 druid 竟然丟擲了空指標異常。原因是，使用了druid的監控，需要經過druid的 Filter 攔截器，但是spr

powermockito單元測試之深入實踐

概述 由於最近工作需要, 在專案中要做單元測試, 以達到指定的測試用例覆蓋率指標。專案中我們引入的powermockito來編寫測試用例, JaCoCo來監控單元測試覆蓋率。關於框架的選擇, 網上討論mockito和powermockito孰優孰劣的文章眾多, 這裡就不多做闡述, 讀者如有興趣可自行了解。