摘要：本文將進(jìn)入單元測(cè)試的部分，這也是基礎(chǔ)知識(shí)中最后一個(gè)大塊。本文將重點(diǎn)講述和中的單元測(cè)試的生態(tài)環(huán)境。另外，在中指定要運(yùn)行的單元測(cè)試用例的完整語(yǔ)法是。中使用模塊管理單元測(cè)試用例。每個(gè)項(xiàng)目的單元測(cè)試代碼結(jié)構(gòu)可

本文將進(jìn)入單元測(cè)試的部分，這也是基礎(chǔ)知識(shí)中最后一個(gè)大塊。本文將重點(diǎn)講述Python和OpenStack中的單元測(cè)試的生態(tài)環(huán)境。

github上有個(gè)人畫了一些不同語(yǔ)言的學(xué)習(xí)曲線圖：Learning Curves (for different programming languages)，雖然有些惡搞的傾向，不過(guò)確實(shí)說(shuō)明了問(wèn)題。這里貼一下Python的部分：

這個(gè)圖說(shuō)明了，會(huì)單元測(cè)試對(duì)于提高Python生產(chǎn)力的重要性，這主要是因?yàn)镻ython是個(gè)動(dòng)態(tài)語(yǔ)言，很多問(wèn)題都無(wú)法通過(guò)靜態(tài)編譯檢查來(lái)發(fā)現(xiàn)，因此單元測(cè)試就成了一個(gè)重要的確保質(zhì)量的手段。OpenStack的核心項(xiàng)目都對(duì)單元測(cè)試有極高的要求，以保證項(xiàng)目的高質(zhì)量。

Python的單元測(cè)試工具很多，為單元測(cè)試提供不同方面的功能。OpenStack的項(xiàng)目也基本把現(xiàn)在流行的單元測(cè)試工具都用全了。單元測(cè)試可以說(shuō)是入門OpenStack開發(fā)的最難的部分，也是最后一公里。本章，我們就介紹一下在OpenStack中會(huì)用到的單元測(cè)試的工具。由于數(shù)量很多，不可能詳細(xì)介紹，因此主要做一些概念和用途上的介紹。

unittest是Python的標(biāo)準(zhǔn)庫(kù)，提供了最基本的單元測(cè)試功能，包括單元測(cè)試運(yùn)行器（簡(jiǎn)稱runner）和單元測(cè)試框架。項(xiàng)目的單元測(cè)試代碼的測(cè)試類可以繼承unittest.TestCase類，這樣這個(gè)類就能夠被runner發(fā)現(xiàn)并且執(zhí)行。同時(shí)，unittest.TestCase這個(gè)類還定義了setUp()，tearDown()，setUpClass()和tearDownClass()方法，是用來(lái)運(yùn)行單元測(cè)試前的設(shè)置工作代碼和單元測(cè)試后的清理工作代碼，這個(gè)也是所有Python代碼遵守的規(guī)范，所以第三方的單元測(cè)試庫(kù)和框架也都遵循這個(gè)規(guī)范。

unittest庫(kù)也提供了一個(gè)runner，可以使用$ python -m unittest test_module的命令來(lái)執(zhí)行某個(gè)模塊的單元測(cè)試。另外，在Python中指定要運(yùn)行的單元測(cè)試用例的完整語(yǔ)法是：path.to.your.module:ClassOfYourTest.test_method。

unittest是學(xué)習(xí)Python單元測(cè)試最基本也最重要的一個(gè)庫(kù)，完整的說(shuō)明請(qǐng)查看官方文檔：https://docs.python.org/2.7/library/unittest.html。

mock也是另一個(gè)重要的單元測(cè)試庫(kù)，在Python 2中是作為一個(gè)第三方庫(kù)被使用的，到Python 3時(shí)，就被納入了標(biāo)準(zhǔn)庫(kù)，可見這個(gè)庫(kù)的重要性。簡(jiǎn)單的說(shuō)，mock就是用來(lái)模擬對(duì)象的行為，這樣在進(jìn)行單元測(cè)試的時(shí)候，可以指定任何對(duì)象的返回值，便于測(cè)試對(duì)外部接口有依賴的代碼。關(guān)于mock的使用，可以查看我之前寫的這篇文章Python Mock的入門

testtools是個(gè)unittest的擴(kuò)展框架，主要是在unittest的基礎(chǔ)上提供了更好的assert功能，使得寫單元測(cè)試更加方便。具體可以查看文檔：http://testtools.readthedocs.org/en/latest/。

fixture的意思是固定裝置，在Python的單元測(cè)試中，是指某段可以復(fù)用的單元測(cè)試setUp和tearDown代碼組合。一個(gè)fixture一般用來(lái)實(shí)現(xiàn)某個(gè)組件的setUp和tearDown邏輯，比如測(cè)試前要先創(chuàng)建好某些數(shù)據(jù)，測(cè)試后要?jiǎng)h掉這些數(shù)據(jù)，這些操作就可以封裝到一個(gè)fixture中。這樣不同的測(cè)試用例就不用重復(fù)寫這些代碼，只要使用fixture即可。fixtures模塊是一個(gè)第三方模塊，提供了一種簡(jiǎn)單的創(chuàng)建fixture類和對(duì)象的機(jī)制，并且也提供了一些內(nèi)置的fixture。具體的使用方法可以查看官方文檔：https://pypi.python.org/pypi/fixtures/。

testscenarios模塊滿足了場(chǎng)景測(cè)試的需求。它的基本用法是在測(cè)試類中添加一個(gè)類屬性scenarios，該屬性是一個(gè)元組，定義了每一種場(chǎng)景下不同的變量的值。比如說(shuō)你測(cè)試一段數(shù)據(jù)訪問(wèn)代碼，你需要測(cè)試該代碼在使用不同的驅(qū)動(dòng)時(shí)，比如MongoDB、SQL、File，是否都能正常工作。我們有三種辦法：

最笨的辦法是為不同的驅(qū)動(dòng)把同一個(gè)測(cè)試用例編寫3遍。

比較好的辦法是，編寫一個(gè)統(tǒng)一的非測(cè)試用例方法，接收driver作為參數(shù)，執(zhí)行測(cè)試邏輯，然后再分別編寫三個(gè)測(cè)試用例方法去調(diào)用這個(gè)非測(cè)試用例方法。

更好的辦法就是使用testscenarios模塊，定義好scenarios變量，然后實(shí)現(xiàn)一個(gè)測(cè)試用例方法。

testscenarios模塊在OpenStack Ceilometer中被大量使用。更多的信息可以查看文檔：https://pypi.python.org/pypi/testscenarios/

subunit是一個(gè)用于傳輸單元測(cè)試結(jié)果的流協(xié)議。一般來(lái)說(shuō)，運(yùn)行單元測(cè)試的時(shí)候是把單元測(cè)試的結(jié)果直接輸出到標(biāo)準(zhǔn)輸出，但是如果運(yùn)行大量的測(cè)試用例，這些測(cè)試結(jié)果就很難被分析。因此就可以使用python-subunit模塊來(lái)運(yùn)行測(cè)試用例，并且把測(cè)試用例通過(guò)subunit協(xié)議輸出，這樣測(cè)試結(jié)果就可以被分析工具聚合以及分析。python-subunit模塊自帶了一些工具用來(lái)解析subunit協(xié)議，比如你可以這樣運(yùn)行測(cè)試用例：$ python -m subunit.run test_module | subunit2pyunit，subunit2pyunit命令會(huì)解析subunit協(xié)議，并且輸出到標(biāo)準(zhǔn)輸出。關(guān)于subunit的更多信息，請(qǐng)查看官方文檔：https://pypi.python.org/pypi/python-subunit/。

OpenStack中使用testrepository模塊管理單元測(cè)試用例。當(dāng)一個(gè)項(xiàng)目中的測(cè)試用例很多時(shí)，如何更有效的處理單元測(cè)試用例的結(jié)果就變得很重要。testrepository的出現(xiàn)就是為了解決這個(gè)問(wèn)題。testrepository使用python-subunit模塊來(lái)運(yùn)行測(cè)試用例，然后分析subunit的輸出并對(duì)測(cè)試結(jié)果進(jìn)行記錄（記錄到本地文件）。舉例來(lái)說(shuō)，testrepository允許你做這樣的事情：

知道哪些用例運(yùn)行時(shí)間最長(zhǎng)

顯示運(yùn)行失敗的用例

重新運(yùn)行上次運(yùn)行失敗的用例

testrepository的更多信息，請(qǐng)查看官方文檔：http://testrepository.readthedocs.org/en/latest/。

coverage是用來(lái)計(jì)算代碼運(yùn)行時(shí)的覆蓋率的，也就是統(tǒng)計(jì)多少代碼被執(zhí)行了。它可以和testrepository一起使用，用來(lái)統(tǒng)計(jì)單元測(cè)試的覆蓋率，在運(yùn)行完單元測(cè)試之后，輸出覆蓋率報(bào)告。具體的使用方法可以查看官方文檔：http://coverage.readthedocs.org/en/latest/。

tox是用來(lái)管理和構(gòu)建虛擬環(huán)境(virtualenv)的。對(duì)于一個(gè)項(xiàng)目，我們需要運(yùn)行Python 2.7的單元測(cè)試，也需要運(yùn)行Python 3.4的單元測(cè)試，還需要運(yùn)行PEP8的代碼檢查。這些不同的任務(wù)需要依賴不同的庫(kù)，所以需要使用不同的虛擬環(huán)境。使用tox的時(shí)候，我們會(huì)在tox的配置文件tox.ini中指定不同任務(wù)的虛擬環(huán)境名稱，該任務(wù)在虛擬環(huán)境中需要安裝哪些包，以及該任務(wù)執(zhí)行的時(shí)候需要運(yùn)行哪些命令。更多信息，請(qǐng)查看官方文檔：https://testrun.org/tox/latest/

本章介紹了OpenStack中常用的單元測(cè)試工具的基本用途，希望大家對(duì)這些工具有個(gè)大概的認(rèn)識(shí)。這里我們可以按照類別總結(jié)一下這些工具：

測(cè)試環(huán)境管理: tox
使用tox來(lái)管理測(cè)試運(yùn)行的虛擬環(huán)境，并且調(diào)用testrepository來(lái)執(zhí)行測(cè)試用例。

測(cè)試用例的運(yùn)行和管理: testrepository, subunit, coverage
testrepository調(diào)用subunit來(lái)執(zhí)行測(cè)試用例，對(duì)測(cè)試結(jié)果進(jìn)行聚合和管理；調(diào)用coverage來(lái)執(zhí)行代碼覆蓋率的計(jì)算。

測(cè)試用例的編寫: unittest, mock, testtools, fixtures, testscenarios
使用testtools作為所有測(cè)試用例的基類，同時(shí)應(yīng)用mock, fixtures, testscenarios來(lái)更好的編寫測(cè)試用例。

在The Hacker"s Guide to Python（《Python高手之路》）一書中，也有專門的一章介紹了各種單元測(cè)試工具及其用法，讀者也可以參考一下。下一章，我們來(lái)分析Keystone項(xiàng)目的單元測(cè)試框架，可以讓你看到在OpenStack的實(shí)際項(xiàng)目中，這些工具是如何被使用的。

現(xiàn)在，我們以Keystone項(xiàng)目為例，來(lái)看下真實(shí)項(xiàng)目中的單元測(cè)試是如何架構(gòu)的。我們采用自頂向下的方式，先從最上層的部分介紹起。

大部分情況下，我們都是通過(guò)tox命令來(lái)執(zhí)行單元測(cè)試的，并且傳遞環(huán)境名稱給tox命令：

? ~/openstack/env/p/keystone git:(master) ? $ tox -e py27

tox命令首先會(huì)讀取項(xiàng)目根目錄下的tox.ini文件，獲取相關(guān)的信息，然后根據(jù)配置構(gòu)建virtualenv，保存在.tox/目錄下，以環(huán)境名稱命名：

? ~/openstack/env/p/keystone git:(master) ? $ ls .tox
log  pep8  py27

除了log目錄，其他的都是普通的virtualenv環(huán)境，你可以自己查看一下內(nèi)容。我們來(lái)看下py27這個(gè)環(huán)境的相關(guān)配置（在tox.ini）中，我直接在內(nèi)容上注釋一些配置的用途：

[tox]
minversion = 1.6
skipsdist = True
# envlist表示本文件中配置的環(huán)境都有哪些
envlist = py34,py27,pep8,docs,genconfig,releasenotes

# testenv是默認(rèn)配置，如果某個(gè)配置在環(huán)境專屬的section中沒(méi)有，就從這個(gè)section中讀取
[testenv]
# usedevelop表示安裝virtualenv的時(shí)候，本項(xiàng)目自己的代碼采用開發(fā)模式安裝，也就是不會(huì)拷貝代碼到virtualenv目錄中，只是做個(gè)鏈接
usedevelop = True
# install_command表示構(gòu)建環(huán)境的時(shí)候要執(zhí)行的命令，一般是使用pip安裝
install_command = pip install -U {opts} {packages}
setenv = VIRTUAL_ENV={envdir}
# deps指定構(gòu)建環(huán)境的時(shí)候需要安裝的依賴包，這個(gè)就是作為pip命令的參數(shù)
# keystone這里使用的寫法比較特殊一點(diǎn)，第二行的.[ldap,memcache,mongodb]是兩個(gè)依賴，第一個(gè)點(diǎn)"."表示當(dāng)前項(xiàng)目的依賴，也就是requirements.txt，第二個(gè)部分[ldap,memcache,mongodb]表示extra，是在setup.cfg文件中定義的一個(gè)段的名稱，該段下定義了額外的依賴，這些可以查看PEP0508
# 一般的項(xiàng)目這里會(huì)采用更簡(jiǎn)單的方式來(lái)書寫，直接安裝兩個(gè)文件中的依賴：
#    -r{toxinidir}/requirements.txt
#    -r{toxinidir}/test-requirements.txt
deps = -r{toxinidir}/test-requirements.txt
       .[ldap,memcache,mongodb]
# commands表示構(gòu)建好virtualenv之后要執(zhí)行的命令，這里調(diào)用了tools/pretty_tox.sh來(lái)執(zhí)行測(cè)試
commands =
  find keystone -type f -name "*.pyc" -delete
  bash tools/pretty_tox.sh "{posargs}"
whitelist_externals =
  bash
  find
passenv = http_proxy HTTP_PROXY https_proxy HTTPS_PROXY no_proxy NO_PROXY PBR_VERSION

# 這個(gè)section是為py34環(huán)境定制某些配置的，沒(méi)有定制的配置，從[testenv]讀取
[testenv:py34]
commands =
  find keystone -type f -name "*.pyc" -delete
  bash tools/pretty_tox_py3.sh

上面提到的PEP-0508是依賴格式的完整說(shuō)明。setup.cfg的extra部分如下：

[extras]
ldap =
  python-ldap>=2.4:python_version=="2.7" # PSF
  ldappool>=1.0:python_version=="2.7" # MPL
memcache =
  python-memcached>=1.56 # PSF
mongodb =
  pymongo!=3.1,>=3.0.2 # Apache-2.0
bandit =
  bandit>=0.17.3 # Apache-2.0

上面我們看到tox.ini文件中的commands參數(shù)中執(zhí)行的是tools/pretty_tox.sh命令。這個(gè)腳本的內(nèi)容如下：

#!/usr/bin/env bash

set -o pipefail

TESTRARGS=$1
# testr和setuptools已經(jīng)集成，所以可以通過(guò)setup.py testr命令來(lái)執(zhí)行
# --testr-args表示傳遞給testr命令的參數(shù)，告訴testr要傳遞給subunit的參數(shù)
# subunit-trace是os-testr包中的命令（os-testr是OpenStack的一個(gè)項(xiàng)目），用來(lái)解析subunit的輸出的。
python setup.py testr --testr-args="--subunit $TESTRARGS" | subunit-trace -f
retval=$?
# NOTE(mtreinish) The pipe above would eat the slowest display from pbr"s testr
# wrapper so just manually print the slowest tests.
echo -e "
Slowest Tests:
"
# 測(cè)試結(jié)束后，讓testr顯示出執(zhí)行時(shí)間最長(zhǎng)的那些測(cè)試用例
testr slowest
exit $retval

tox就是從tools/pretty_tox.sh這個(gè)命令開始調(diào)用testr來(lái)執(zhí)行單元測(cè)試的。testr本身的配置是放在項(xiàng)目根目錄下的.testr.conf文件：

[DEFAULT]
test_command=
    ${PYTHON:-python} -m subunit.run discover -t ./ ${OS_TEST_PATH:-./keystone/tests/unit} $LISTOPT $IDOPTION

test_id_option=--load-list $IDFILE
test_list_option=--list
group_regex=.*(test_cert_setup)


# NOTE(morganfainberg): If single-worker mode is wanted (e.g. for live tests)
# the environment variable ``TEST_RUN_CONCURRENCY`` should be set to ``1``. If
# a non-default (1 worker per available core) concurrency is desired, set
# environment variable ``TEST_RUN_CONCURRENCY`` to the desired number of
# workers.
test_run_concurrency=echo ${TEST_RUN_CONCURRENCY:-0}

這個(gè)文件中的配置項(xiàng)可以從testr官方文檔中找到。其中test_command命令表示要執(zhí)行什么命令來(lái)運(yùn)行測(cè)試用例，這里使用的是subunit.run，這個(gè)我們?cè)谏厦嫣岬竭^(guò)了。

到目前為止的流程就是：

tox建好virtualenv

tox調(diào)用testr

testr調(diào)用subunit來(lái)執(zhí)行測(cè)試用例

每個(gè)OpenStack項(xiàng)目基本上也都是這樣。如果你自己在開發(fā)一個(gè)Python項(xiàng)目，你也可以參考這個(gè)架構(gòu)。

下面我們來(lái)看一下Keystone的單元測(cè)試代碼是如何寫的，主要是看一下其層次結(jié)構(gòu)。每個(gè)OpenStack項(xiàng)目的單元測(cè)試代碼結(jié)構(gòu)可能都不一樣，不過(guò)你了解完Keystone的結(jié)構(gòu)之后，看其他項(xiàng)目的就會(huì)比較快了。

我們以一個(gè)測(cè)試類為例來(lái)分析測(cè)試代碼的結(jié)構(gòu)：keystone.tests.unit.test_v3_assignment:AssignmentTestCase。下面是這個(gè)類的繼承結(jié)構(gòu)，同一級(jí)別的縮進(jìn)表示多重繼承，增加縮進(jìn)表示父類，這里刪掉了不必要的路徑前綴（從unit目錄開始），如下所示：

# 這個(gè)測(cè)試類是測(cè)RoleAssignment的API的
unit.test_v3_assignment.RoleAssignmentBaseTestCase
-> unit.test_v3.AssignmentTestMixin  這個(gè)類包含了一下測(cè)試Assignment的工具函數(shù)
-> unit.test_v3.RestfulTestCase      這個(gè)類是進(jìn)行V3 REST API測(cè)試的基類，實(shí)現(xiàn)了V3 API的請(qǐng)求發(fā)起和校驗(yàn)
  -> unit.core.SQLDriverOverride     用于修改各個(gè)配置的driver字段為sql
  -> unit.test_v3.AuthTestMixin      包含創(chuàng)建認(rèn)證請(qǐng)求的輔助函數(shù)
  -> unit.rest.RestfulTestCase       這個(gè)類是進(jìn)行RESP API測(cè)試的基類，V2和V3的API測(cè)試都是以這個(gè)類為基類，這個(gè)類的setUp方法會(huì)初始化數(shù)據(jù)庫(kù)，創(chuàng)建好TestApp。
    -> unit.TestCase                 這個(gè)類是Keystone中所有單元測(cè)試類的基類，它主要初始化配置，以及初始化log
      -> unit.BaseTestCase           這個(gè)類主要是配置測(cè)試運(yùn)行的基本環(huán)境，修改一些環(huán)境變量，比如HOME等。
        -> oslotest.BaseTestCase     這個(gè)是在oslotest中定義的基類，原來(lái)所有的OpenStack項(xiàng)目的單元測(cè)試都繼承自這個(gè)基類。
                                     不過(guò)，這個(gè)繼承在Keystone中已經(jīng)被刪除了，Keystone自己在unit.BaseTestCase中做了差不多的事情。
                                     這個(gè)是2016-02-17做的變更，具體的可以查看這個(gè)revision 262d0b66c3bcb82eadb663910ee21ded63e77a78。
          -> testtools.TestCase      使用testtools作為測(cè)試框架
            -> unittest.TestCase     testtools本身是unittest的擴(kuò)展

從上面的層次結(jié)構(gòu)可以看出，OpenStack中的大項(xiàng)目，由于單元測(cè)試用例很多（Keystone現(xiàn)在有超過(guò)6200個(gè)單元測(cè)試用例），所以其單元測(cè)試架構(gòu)也會(huì)比較復(fù)雜。要寫好單元測(cè)試，需要先了解一下整個(gè)測(cè)試代碼的架構(gòu)。

本文我們了解了Python中的單元測(cè)試的概念和工具，并且通過(guò)Keystone項(xiàng)目了解了實(shí)際項(xiàng)目中的單元測(cè)試的架構(gòu)，希望有助于各位讀者更好的掌握OpenStack項(xiàng)目的單元測(cè)試基礎(chǔ)。webdemo項(xiàng)目目前沒(méi)有單元測(cè)試的代碼，有興趣的讀者可以自己fork然后參考Keystone的架構(gòu)為其增加完整的單元測(cè)試架構(gòu)。

這個(gè)系列我打算就此結(jié)束，到目前為止一共寫了8篇文章，寫寫停停，前后寫了9個(gè)月。這里也做個(gè)小結(jié)。

一開始寫這個(gè)系列的文章是因?yàn)槲易约涸趯W(xué)習(xí)OpenStack開發(fā)的過(guò)程中遇到很多困難，很難找到所需的入門文章。所以打算寫點(diǎn)文章，既能作為自己的總結(jié)，也能為其他人提供些幫助。如果這些文章能幫到你，我就非常的開心。當(dāng)然，這些文章的質(zhì)量肯定有好有壞，歡迎大家提意見，如果有時(shí)間，我會(huì)繼續(xù)修改。

然后，我想說(shuō)一下寫這類文章的難點(diǎn)，主要是要保證細(xì)節(jié)都是正確的，然后又不能太啰嗦。

細(xì)節(jié)都是正確的。舉個(gè)例子，大學(xué)的很多數(shù)據(jù)結(jié)構(gòu)教材中的代碼，你直接貼到電腦上，然后編譯，大部分是編譯不通過(guò)的。這個(gè)會(huì)讓初學(xué)者非常沮喪。所以我希望能夠保證這些文章里的細(xì)節(jié)都是正確的，包括一些工具的配置，如果覺得有必要，我也會(huì)描述下配置的作用，以及要去哪里找更多的信息。如果這方面有遺漏，請(qǐng)和我說(shuō)。

不能太啰嗦。這8篇文章里涉及的庫(kù)有好幾十個(gè)，每個(gè)庫(kù)如果都講仔細(xì)了，那就會(huì)讓文章顯得非常啰嗦。但是又不能直接讓讀者去看庫(kù)的官方文檔，所以權(quán)衡內(nèi)容也是很麻煩的。如果各位有這方面的建議，也請(qǐng)和我說(shuō)。

這個(gè)系列的文章是關(guān)于OpenStack的基礎(chǔ)知識(shí)，其實(shí)OpenStack開發(fā)還要涉及到很多其他的知識(shí)，比如消息隊(duì)列、非阻塞IO等，而且還要了解整個(gè)OpenStack的開發(fā)生態(tài)，包括Gerrit評(píng)審系統(tǒng)、Zuul持續(xù)集成、devstack開發(fā)環(huán)境、oslo項(xiàng)目等。