軟件開發公司，本文將進入單元測試的部分，這也是基礎知識中較后一個大塊。本文將重點講述Python和OpenStack中的單元測試的生態環境。

　　通過demo學習OpenStack開發——單元測試

　　單元測試的重要性

　　單元測試工具

　　unittest

　　mock

　　testtools

　　fixtures

　　testscenarios

　　subunit

　　testrepository

　　coverage

　　tox

　　單元測試工具小結

　　Keystone的單元測試框架

　　使用tox進行測試環境管理

　　使用testrepository管理測試的運行

　　單元測試用例的代碼架構

　　總結

　　系列后記

　　單元測試的重要性

　　GitHub上有個人畫了一些不同語言的學習曲線圖：Learning Curves (for different programming languages)，雖然有些惡搞的傾向，不過確實說明了問題。這里貼一下Python的部分：

　　這個圖說明了，會單元測試對于提高Python生產力的重要性，這主要是因為Python是個動態語言，很多問題都無法通過靜態編譯檢查來發現，因此單元測試就成了一個重要的確保質量的手段。OpenStack的核心項目都對單元測試有極高的要求，以保證項目的高質量。

　　單元測試工具

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

　　unittest

　　unittest是Python的標準庫，提供了較基本的單元測試功能，包括單元測試運行器(簡稱runner)和單元測試框架。項目的單元測試代碼的測試類可以繼承unittest.TestCase類，這樣這個類就能夠被runner發現并且執行。同時，unittest.TestCase這個類還定義了setUp()，tearDown()，setUpClass()和tearDownClass()方法，是用來運行單元測試前的設置工作代碼和單元測試后的清理工作代碼，這個也是所有Python代碼遵守的規范，所以第三方的單元測試庫和框架也都遵循這個規范。

　　unittest庫也提供了一個runner，可以使用$ python -m unittest test_module的命令來執行某個模塊的單元測試。另外，在Python中指定要運行的單元測試用例的完整語法是：path.to.your.module:ClassOfYourTest.test_method。

　　unittest是學習Python單元測試較基本也較重要的一個庫，完整的說明請查看官方文檔。

　　mock

　　mock也是另一個重要的單元測試庫，在Python 2中是作為一個第三方庫被使用的，到Python 3時，就被納入了標準庫，可見這個庫的重要性。簡單的說，mock就是用來模擬對象的行為，這樣在進行單元測試的時候，可以指定任何對象的返回值，便于測試對外部接口有依賴的代碼。關于mock的使用，可以查看我之前寫的這篇文章Python Mock的入門。

　　testtools

　　testtools是個unittest的擴展框架，主要是在unittest的基礎上提供了更好的assert功能，使得寫單元測試更加方便。具體可以查看文檔。

　　fixtures

　　fixture的意思是固定裝置，在Python的單元測試中，是指某段可以復用的單元測試setUp和tearDown代碼組合。一個fixture一般用來實現某個組件的setUp和tearDown邏輯，比如測試前要先創建好某些數據，測試后要刪掉這些數據，這些操作就可以封裝到一個fixture中。這樣不同的測試用例就不用重復寫這些代碼，只要使用fixture即可。fixtures模塊是一個第三方模塊，提供了一種簡單的創建fixture類和對象的機制，并且也提供了一些內置的fixture。具體的使用方法可以查看官方文檔。

　　testscenarios

　　testscenarios模塊滿足了場景測試的需求。它的基本用法是在測試類中添加一個類屬性scenarios，該屬性是一個元組，定義了每一種場景下不同的變量的值。比如說你測試一段數據訪問代碼，你需要測試該代碼在使用不同的驅動時，比如MongoDB、SQL、File，是否都能正常工作。我們有三種辦法：

　　較笨的辦法是為不同的驅動把同一個測試用例編寫3遍。

　　比較好的辦法是，編寫一個統一的非測試用例方法，接收driver作為參數，執行測試邏輯，然后再分別編寫三個測試用例方法去調用這個非測試用例方法。

　　更好的辦法就是使用testscenarios模塊，定義好scenarios變量，然后實現一個測試用例方法。

　　testscenarios模塊在OpenStack Ceilometer中被大量使用。更多的信息可以查看文檔。

　　subunit

　　subunit是一個用于傳輸單元測試結果的流協議。一般來說，運行單元測試的時候是把單元測試的結果直接輸出到標準輸出，但是如果運行大量的測試用例，這些測試結果就很難被分析。因此就可以使用python-subunit模塊來運行測試用例，并且把測試用例通過subunit協議輸出，這樣測試結果就可以被分析工具聚合以及分析。python-subunit模塊自帶了一些工具用來解析subunit協議，比如你可以這樣運行測試用例：$ python -m subunit.run test_module | subunit2pyunit，subunit2pyunit命令會解析subunit協議，并且輸出到標準輸出。關于subunit的更多信息，請查看官方文檔。

　　testrepository

　　OpenStack中使用testrepository模塊管理單元測試用例。當一個項目中的測試用例很多時，如何更有效的處理單元測試用例的結果就變得很重要。testrepository的出現就是為了解決這個問題。testrepository使用python-subunit模塊來運行測試用例，然后分析subunit的輸出并對測試結果進行記錄(記錄到本地文件)。舉例來說，testrepository允許你做這樣的事情：

　　知道哪些用例運行時間較長

　　顯示運行失敗的用例

　　重新運行上次運行失敗的用例

　　testrepository的更多信息，請查看官方文檔。

　　coverage

　　coverage是用來計算代碼運行時的覆蓋率的，也就是統計多少代碼被執行了。它可以和testrepository一起使用，用來統計單元測試的覆蓋率，在運行完單元測試之后，輸出覆蓋率報告。具體的使用方法可以查看官方文檔。

　　tox

　　tox是用來管理和構建虛擬環境(virtualenv)的。對于一個項目，我們需要運行Python 2.7的單元測試，也需要運行Python 3.4的單元測試，還需要運行PEP8的代碼檢查。這些不同的任務需要依賴不同的庫，所以需要使用不同的虛擬環境。使用tox的時候，我們會在tox的配置文件tox.ini中指定不同任務的虛擬環境名稱，該任務在虛擬環境中需要安裝哪些包，以及該任務執行的時候需要運行哪些命令。更多信息，請查看官方文檔。

　　單元測試工具小結

　　本章介紹了OpenStack中常用的單元測試工具的基本用途，希望大家對這些工具有個大概的認識。這里我們可以按照類別總結一下這些工具：

　　測試環境管理: tox

　　使用tox來管理測試運行的虛擬環境，并且調用testrepository來執行測試用例。

　　測試用例的運行和管理: testrepository, subunit, coverage

　　testrepository調用subunit來執行測試用例，對測試結果進行聚合和管理;調用coverage來執行代碼覆蓋率的計算。

　　測試用例的編寫: unittest, mock, testtools, fixtures, testscenarios

　　使用testtools作為所有測試用例的基類，同時應用mock, fixtures, testscenarios來更好的編寫測試用例。

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