以前我是不寫任何測(cè)試的，后來(lái)偶爾寫單元測(cè)試，現(xiàn)在我主動(dòng)寫單元測(cè)試 ----- 不得 不承認(rèn)，測(cè)試是有其存在必要性的，要說(shuō)為什么的話，大概又會(huì)引發(fā)語(yǔ)言的強(qiáng)弱類型和 是否靜態(tài)語(yǔ)言之爭(zhēng)了吧。

就目前而言，個(gè)人認(rèn)為寫單元測(cè)試的好處有以下幾點(diǎn)：

當(dāng)修改了代碼之后，單元測(cè)試可以保證API不會(huì)發(fā)生變化（假設(shè)原需求就不需API發(fā)生 變化）。這點(diǎn)可能一般情況下沒什么感覺，但是當(dāng)你去修改前輩留下的代碼的時(shí)候， 你就會(huì)感謝他寫了單元測(cè)試，最少讓你知道了從功能上，這個(gè)函數(shù)是干什么的，而且 能保證你修改了函數(shù)內(nèi)部實(shí)現(xiàn)，但是不影響函數(shù)功能。

寫單元測(cè)試的時(shí)候會(huì)回想函數(shù)的作用，從而自動(dòng)對(duì)函數(shù)進(jìn)行回想和 review。

缺點(diǎn)嘛：耗費(fèi)時(shí)間。單元測(cè)試和文檔一樣，屬于非常重要，但是非常耗費(fèi)時(shí)間的工作， 因?yàn)橐紤]齊全，考慮到的邊界條件越多，測(cè)試覆蓋率越高，程序越可靠，而想這些東 西是很耗費(fèi)時(shí)間精力的。

吐槽完畢，我們來(lái)說(shuō)說(shuō)目前我知道的幾個(gè)和測(cè)試有關(guān)的東西(全程 Python 3)。

Mock

Mock是個(gè)好東西呀，遇到測(cè)試中出現(xiàn)的不可預(yù)知的或者不穩(wěn)定因素，就用 Mock 來(lái)代 替。例如查詢數(shù)據(jù)庫(kù)（當(dāng)然像目前我們用的MongoDB，由于特別靈活，可以直接在代碼里 把相應(yīng)的collection替換掉），例如異步任務(wù)等。舉個(gè)例子：

import logging from unittest.mock import Mock logging.basicConfig(level=logging.DEBUG) # code class ASpecificException(Exception):pass def foo():pass def bar():try:logging.info("enter function <foo> now")foo()except ASpecificException:logging.exception("we caught a specific exception") # unittest def test_foo():foo = Mock(side_effect=ASpecificException()) # noqalogging.info("enter function <bar> now")bar()logging.info("everything just be fine") if __name__ == "__main__":test_foo()

運(yùn)行一下：

root@arch tests: python test_demo.py INFO:root:enter function <bar> now INFO:root:enter function <foo> now INFO:root:everything just be fine

一個(gè)簡(jiǎn)單的測(cè)試就這么寫好了。來(lái)，跟我念，Mock 大法好呀！

doctest

doctest屬于比較簡(jiǎn)單的測(cè)試，寫在 docstring 里，這樣既能測(cè)試用，又能當(dāng)文檔 示例，是在是好用之極啊。缺點(diǎn)是，如果測(cè)試太復(fù)雜，doctest就顯得太臃腫了（例如 如果測(cè)試之前要導(dǎo)入一堆東西）。舉個(gè)例子：

import logging logging.basicConfig(level=logging.DEBUG) def foo():"""A utility function that returns True>>> foo()True"""return True if __name__ == "__main__":import doctestlogging.debug("start of test...")doctest.testmod()logging.debug("end of test...")

測(cè)試結(jié)果：

root@arch tests: python test_demo.py DEBUG:root:start of test... DEBUG:root:end of test...

unittest

這個(gè)文檔確實(shí)有點(diǎn)長(zhǎng)，我感覺還是仔細(xì)去讀一下文檔比較好（雖然我也沒讀完）。

import unittest class TestStringMethods(unittest.TestCase):def setUp(self):self.alist = []def tearDown(self):print(self.alist)def test_list(self):for i in range(5):self.alist.append(i) if __name__ == '__main__':unittest.main() root@arch tests: python test_demo.py [0, 1, 2, 3, 4] . ---------------------------------------------------------------------- Ran 1 test in 0.001s

OK

unittest框架配合上Mock，單元測(cè)試基本無(wú)憂啦。

pytest

上面的單元測(cè)試跑起來(lái)比較麻煩，當(dāng)然也可以寫一個(gè)腳本遍歷所有的單元測(cè)試文件，然 后執(zhí)行。不過 pytest 對(duì)unittest有比較好的支持。

pytest默認(rèn)支持的是 函數(shù) 風(fēng)格的測(cè)試，但是我們可以不用這一塊嘛（而且很多時(shí)候 還是很有用的）。走進(jìn)項(xiàng)目根目錄，輸入 pytest 就可以啦。它會(huì)自動(dòng)發(fā)現(xiàn) test_ 開頭的文件，然后執(zhí)行其中 test_ 開頭的函數(shù)和 unittest 的 test_ 開頭的 方法。

root@arch tests: pytest ========================================================= test session starts ========================================================= platform linux -- Python 3.5.2, pytest-3.0.5, py-1.4.31, pluggy-0.4.0 rootdir: /root/tests, inifile: collected 1 items test_afunc.py . ====================================================== 1 passed in 0.03 seconds ======================================================= root@arch tests:

總結(jié)

編譯器沒給python做檢查，就只有靠我們手寫測(cè)試了 😦

另外其實(shí) pytest 和 unittest 都有很多強(qiáng)大的特性，例如 fixture（不知道 咋翻譯好），例如 skip 掉某一部分測(cè)試。當(dāng)然我也是知之甚少，所以還是看文檔吧。

總結(jié)

以上是生活随笔為你收集整理的Python和单元测试那些事儿的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。