我們知道，在軟件工程中，單元測(cè)試是保證軟件質(zhì)量的重要手段之一。一個(gè)優(yōu)秀的代碼，單元測(cè)試的代碼量，經(jīng)常會(huì)超過被測(cè)試的代碼本身。一個(gè)理想化的開發(fā)團(tuán)隊(duì)，可能有三分之二的時(shí)間是在寫測(cè)試，剩下的三分之一時(shí)間才是寫業(yè)務(wù)代碼。

如果你的項(xiàng)目是從一開始就寫單元測(cè)試，那么你寫起來(lái)應(yīng)該輕松又愉快，因?yàn)閱卧獪y(cè)試會(huì)促使你的代碼自身變成可測(cè)試的代碼。

但如果你接手了一個(gè)大項(xiàng)目，里面已經(jīng)有幾十萬(wàn)行代碼了，那么給這些代碼補(bǔ)單元測(cè)試會(huì)讓你知道什么叫做痛不欲生。你會(huì)發(fā)現(xiàn)有一些函數(shù)，它讓你不知道怎么寫測(cè)試代碼。但你又不能隨便修改代碼的結(jié)構(gòu)，誰(shuí)知道會(huì)引起什么連鎖反應(yīng)？

我們來(lái)看一個(gè)例子：

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

而且，就算Redis和MySQL沒有故障，你怎么知道你的data_id和pk，在數(shù)據(jù)庫(kù)中對(duì)應(yīng)的是什么數(shù)據(jù)？為了分別走到特定的分支，你還需要去檢測(cè)數(shù)據(jù)庫(kù)中特定數(shù)據(jù)的id。萬(wàn)一是測(cè)試環(huán)境，別人修改了里面的數(shù)據(jù)，你的測(cè)試也可能會(huì)掛掉。

如果直接使用Pytest來(lái)寫測(cè)試案例，代碼是這樣的：

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

難道為了讓單元測(cè)試進(jìn)行下去，我還要去數(shù)據(jù)庫(kù)構(gòu)造一條特定的數(shù)據(jù)？這只是單元測(cè)試，又不是集成測(cè)試。

為了解決這個(gè)問題，我們就可以使用mock模塊。這是Python自帶的一個(gè)模塊，可以動(dòng)態(tài)替換函數(shù)。

它的寫法非常簡(jiǎn)單：

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

從上圖可以看到，test_runner.py?運(yùn)行以后，原本在read_data_from_redis和read_data_from_mysql中打印的兩段文字都沒有打印，說明這兩個(gè)函數(shù)已經(jīng)被動(dòng)態(tài)替換了，他們內(nèi)部的代碼不會(huì)運(yùn)行。只會(huì)直接返回我們預(yù)設(shè)的這個(gè)返回值。這樣一來(lái)就跟數(shù)據(jù)庫(kù)解耦了。

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

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

mock.path有一個(gè)小坑，一定要注意。我們來(lái)看看下面這個(gè)文件結(jié)構(gòu)：

read_data_from_redis和read_data_from_mysql?兩個(gè)函數(shù)分布在了不同的文件里面。在runner.py?中導(dǎo)入并使用了他們。test_runner.py?中，我們使用@mock.patch對(duì)這兩個(gè)函數(shù)定義的路徑打補(bǔ)丁進(jìn)行替換?？墒翘鎿Q了以后，運(yùn)行Pytest，會(huì)發(fā)現(xiàn)這兩個(gè)函數(shù)竟然正常運(yùn)行了。也就是說我們的替換失敗了。

之所以會(huì)出現(xiàn)這種情況，是因?yàn)槲覀円蜓a(bǔ)丁的并不是這兩個(gè)函數(shù)定義的地方，而是使用的地方。我們?cè)趓unner.py中，分別使用如下兩個(gè)語(yǔ)句：

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

導(dǎo)入了這兩個(gè)函數(shù)，我們也是在runner.py?中使用他們的。因此，@mock.patch?的第一個(gè)參數(shù)，依然應(yīng)該是runner.read_data_from_redis和runner.read_data_from_mysql。

正確的做法如下圖所示：

mock.patch?還有更多高級(jí)用法，例如替換類，替換實(shí)例方法等等?？梢栽趗nittest.mock中找到他。從Python 3.3開始，官方自帶了unittest.mock?，它跟直接import mock的效果是一樣的。