我們知道，在軟件工程中，單元測試是保證軟件質量的重要手段之一。一個優秀的代碼，單元測試的代碼量，經常會超過被測試的代碼本身。一個理想化的開發團隊，可能有三分之二的時間是在寫測試，剩下的三分之一時間才是寫業務代碼。

如果你的項目是從一開始就寫單元測試，那么你寫起來應該輕松又愉快，因為單元測試會促使你的代碼自身變成可測試的代碼。

但如果你接手了一個大項目，里面已經有幾十萬行代碼了，那么給這些代碼補單元測試會讓你知道什么叫做痛不欲生。你會發現有一些函數，它讓你不知道怎么寫測試代碼。但你又不能隨便修改代碼的結構，誰知道會引起什么連鎖反應？

我們來看一個例子：

我想測試的是business_code?里面，check_data_dup分別返回True或者False的時候，下面代碼的邏輯。也就是說，我只關心第18-27行的邏輯。這個時候不關心MySQL和Redis。但是每次測試都要從他們里面讀取數據，這樣就會導致測試代碼依賴外部環境。如果MySQL或者Redis掛了，那么測試代碼就會運行失敗。

而且，就算Redis和MySQL沒有故障，你怎么知道你的data_id和pk，在數據庫中對應的是什么數據？為了分別走到特定的分支，你還需要去檢測數據庫中特定數據的id。萬一是測試環境，別人修改了里面的數據，你的測試也可能會掛掉。

如果直接使用Pytest來寫測試案例，代碼是這樣的：

可以看到，我運行Pytest以后，成功了一個，失敗了一個。這里我模擬出數據庫中沒有數據能夠讓check_data_dup?走到返回True邏輯的情況。

難道為了讓單元測試進行下去，我還要去數據庫構造一條特定的數據？這只是單元測試，又不是集成測試。

為了解決這個問題，我們就可以使用mock模塊。這是Python自帶的一個模塊，可以動態替換函數。

它的寫法非常簡單：

我們只需要使用@mock.patch裝飾器，裝飾測試函數就可以了。這個裝飾器接收兩個參數，第一個參數是被模擬的函數的路徑，以點分割；第二個參數是你想讓它返回的值。

從上圖可以看到，test_runner.py?運行以后，原本在read_data_from_redis和read_data_from_mysql中打印的兩段文字都沒有打印，說明這兩個函數已經被動態替換了，他們內部的代碼不會運行。只會直接返回我們預設的這個返回值。這樣一來就跟數據庫解耦了。

注意，在上圖中，由于我們已經mock了check_data_dup?，因此read_data_from_redis和read_data_from_mysql?兩個函數隨便返回什么值都可以。如果你想順帶也測試一下check_data_dup，那么可以不mock它，如下圖所示。

在check_data_dup?函數的邏輯中，如果data?參數含有字符x?，并且user_id?是偶數，就返回True?，否則返回False?。我們通過mock兩個讀數據的函數，分別設置不同的返回值，就能滿足讓check_data_dup返回不同值的條件。

mock.path有一個小坑，一定要注意。我們來看看下面這個文件結構：

read_data_from_redis和read_data_from_mysql?兩個函數分布在了不同的文件里面。在runner.py?中導入并使用了他們。test_runner.py?中，我們使用@mock.patch對這兩個函數定義的路徑打補丁進行替換。可是替換了以后，運行Pytest，會發現這兩個函數竟然正常運行了。也就是說我們的替換失敗了。

之所以會出現這種情況，是因為我們要打補丁的并不是這兩個函數定義的地方，而是使用的地方。我們在runner.py中，分別使用如下兩個語句：

from mysql_util.SqlUtil import read_data_from_mysql
from controller.lib.redis.RedisUtil import read_data_from_redis

導入了這兩個函數，我們也是在runner.py?中使用他們的。因此，@mock.patch?的第一個參數，依然應該是runner.read_data_from_redis和runner.read_data_from_mysql。

正確的做法如下圖所示：

mock.patch?還有更多高級用法，例如替換類，替換實例方法等等。可以在unittest.mock中找到他。從Python 3.3開始，官方自帶了unittest.mock?，它跟直接import mock的效果是一樣的。