我們的測試用例是相當簡單的,但當它每次運行時,一個臨時文件被創建然后被刪除。此外,我們沒有辦法去測試我們的rm方法是否傳遞參數到os.remove中。我們可以假設它是基于上面的測試,但仍有許多需要被證實。
重構與模擬測試
讓我們使用mock重構我們的測試用例:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
#!/usr/bin/env python # -*- coding: utf-8 -*- from mymodule import rm import mock import 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") |
對于這些重構,我們已經從根本上改變了該測試的運行方式?,F在,我們有一個內部的對象,讓我們可以使用另一個功能驗證。
潛在的陷阱
第一件要注意的事情就是,我們使用的mock.patch方法的裝飾位于mymodule.os模擬對象,并注入到我們測試案例的模擬方法。是模擬os更有意義,還是它在mymodule.os的參考更有意義?
當然,當Python出現在進口和管理模塊時,用法是非常的靈活。在運行時,該mymodule模塊有自己的os操作系統——被引入到自己的范圍內的模塊。因此,如果我們模擬os系統,我們不會看到模擬測試在mymodule模塊的影響。
這句話需要深刻的記?。?/p>
模擬測試一個項目,只需要了解它用在哪里,而不是它從哪里來.
如果你需要為myproject.app.MyElaborateClass模擬tempfile模型,你可能需要去模擬myproject.app.tempfile的每個模塊來保持自己的進口。
這就是用陷阱的方式來模擬測試。
向’rm’中加入驗證
之前定義的 rm 方法相當的簡單 . 在盲目的刪除之前,我們會拿它來驗證一個路徑是否存在,并驗證其是否是一個文件. 讓我們重構 rm 使其變得更加聰明:
1 2 3 4 5 6 7 8 9 |
#!/usr/bin/env python # -*- coding: utf-8 -*- import os import os.path def rm(filename): if os.path.isfile(filename): os.remove(filename) |
很好. 現在,讓我們調整我們的測試用例來保持測試的覆蓋程度.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
#!/usr/bin/env python # -*- coding: utf-8 -*- from mymodule import rm import mock import 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") |
原文轉自:http://www.diggerplus.org/archives/2704