為何需要個編寫準(zhǔn)則？

單元測試比實際實現(xiàn)可能還要難一些，它強(qiáng)迫你考慮清楚一些事情。

但單元測試本身應(yīng)該簡單、直接、易用和易于維護(hù)。

還要知道何時停止寫測試并且開始寫實現(xiàn)。

使用這個原則能夠確保有效測試且達(dá)到目標(biāo)，幫助避免一些明顯的錯誤。

記住，編寫糟糕的測試是在浪費時間，并會在以后造成更大的問題。

實施單元測試的時候, 如果沒有一份經(jīng)過實踐證明的詳細(xì)規(guī)范, 很難掌握測試的 “度”, 范圍太小施展不開, 太大又侵犯 “別人的” 地盤. 上帝的歸上帝, 凱撒的歸凱撒, 給單元測試念念緊箍咒不見得是件壞事, 反而更有利于發(fā)揮單元測試的威力, 為代碼重構(gòu)和提高代碼質(zhì)量提供動力.

1. 保持單元測試小巧, 快速

理論上, 任何代碼提交前都應(yīng)該完整跑一遍所有測試套件. 保持測試代碼執(zhí)行快能夠縮短迭代開發(fā)周期.

2. 單元測試應(yīng)該是全自動/非交互式的

測試套件通常是定期執(zhí)行的, 執(zhí)行過程必須完全自動化才有意義. 輸出結(jié)果需要人工檢查的測試不是一個好的單元測試.

3. 讓單元測試很容易跑起來

對開發(fā)環(huán)境進(jìn)行配置, 最好是敲一條命令或是點擊一個按鈕就能把單個測試用例或測試套件跑起來.

4. 對測試進(jìn)行評估

對執(zhí)行的測試進(jìn)行覆蓋率分析, 得到精確的代碼執(zhí)行覆蓋率, 并調(diào)查哪些代碼未被執(zhí)行.

5. 立即修正失敗的測試

每個開發(fā)人員在提交前都應(yīng)該保證新的測試用例執(zhí)行成功, 當(dāng)有代碼提交時, 現(xiàn)有測試用例也都能跑通.

如果一個定期執(zhí)行的測試用例執(zhí)行失敗, 整個團(tuán)隊?wèi)?yīng)該放下手上的工作先解決這個問題.

6. 把測試維持在單元級別

單元測試即類 (Class) 的測試. 一個 “測試類” 應(yīng)該只對應(yīng)于一個 “被測類”, 并且 “被測類” 的行為應(yīng)該被隔離測試. 必須謹(jǐn)慎避免使用單元測試框架來測試整個程序的工作流, 這樣的測試即低效又難維護(hù). 工作流測試 (譯注: 指跨模塊/類的數(shù)據(jù)流測試) 有它自己的地盤, 但它絕不是單元測試, 必須單獨建立和執(zhí)行.

7. 由簡入繁

再簡單的測試也遠(yuǎn)遠(yuǎn)勝過完全沒有測試. 一個簡單的 “測試類” 會促使建立 “被測類” 基本的測試骨架, 可以對構(gòu)建環(huán)境, 單元測試環(huán)境, 執(zhí)行環(huán)境以及覆蓋率分析工具等有效性進(jìn)行檢查, 同時也可以證明 “被測類” 能夠被整合和調(diào)用.

下面便是單元測試版的 Hello, world! :

void testDefaultConstruction()
{
Foo foo = new Foo();
assertNotNull(foo);
}

8. 保持測試的獨立性

為了保證測試穩(wěn)定可靠且便于維護(hù), 測試用例之間決不能有相互依賴, 也不能依賴執(zhí)行的先后次序.

9. Keep tests close to the class being tested

[譯注: 有意翻譯該規(guī)則, 個人認(rèn)為本條規(guī)則值得商榷, 大部分 C++, Objective-C和 Python 庫均把測試代碼從功能代碼目錄中獨立出來, 通常是創(chuàng)建一個和 src 目錄同級的 tests 目錄, 被測模塊/類名之前也常常 不加 Test 前綴. 這么做保證功能代碼和測試代碼隔離, 目錄結(jié)構(gòu)清晰, 并且發(fā)布源碼的時候更容易排除測試用例.]

If the class to test is Foo the test class should be called FooTest (not TestFoo) and kept in the same package (directory) as Foo. Keeping test classes in separate directory trees makes them harder to access and maintain.
 
Make sure the build environment is configured so that the test classes doesn't make its way into production libraries or executables.

10. 合理的命名測試用例

確保每個方法只測試 “被測類” 的一個明確特性, 并相應(yīng)的命名測試方法. 典型的命名俗定是test[what], 比如testSaveAs(), testAddListener(), testDeleteProperty() 等.

11. 只測公有接口

單元測試可以被定義為 通過類的公有 API 對類進(jìn)行測試. 一些測試工具允許測試一個類的私有成員, 但這種做法應(yīng)該避免, 它讓測試變得繁瑣而且更難維護(hù). 如果有私有成員確實需要進(jìn)行直接測試, 可以考慮把它重構(gòu)到工具類的公有方法中. 但要注意這么做是為了改善設(shè)計, 而不是幫助測試.

12. 看成是黑盒

站在第三方使用者的角度, 測試一個類是否滿足規(guī)定的需求. 并設(shè)法讓它出問題.

13. 看成是白盒

畢竟被測試類是程序員自寫自測的, 應(yīng)該在最復(fù)雜的邏輯部分多花些精力測試.

14. 芝麻函數(shù)也要測試

通常建議所有重要的函數(shù)都應(yīng)該被測試到, 一些芝麻方法比如簡單的 setter 和 getter 都可以忽略. 但是仍然有充分的理由支持測試芝麻函數(shù):

芝麻 很難定義. 對于不同的人有不同的理解.

從黑盒測試的觀點看, 是無法知道哪些代碼是芝麻級別的.

即便是再芝麻的函數(shù), 也可能包含錯誤, 通常是 “復(fù)制粘貼” 代碼的后果:

private double weight_;
private double x_, y_;
 
public void setWeight(int weight)
{
  weight = weight_;  // error
}
 
public double getX()
{
  return x_;
}
 
public double getY()
{
  return x_;  // error
}

因此建議測試所有方法. 畢竟芝麻用例也容易測試.

15. 先關(guān)注執(zhí)行覆蓋率

區(qū)別對待 執(zhí)行覆蓋率 和 實際測試覆蓋率. 測試的最初目標(biāo)應(yīng)該是確保較高的執(zhí)行覆蓋率. 這樣能保證代碼在 少量 參數(shù)值輸入時能執(zhí)行成功. 一旦執(zhí)行覆蓋率就緒, 就應(yīng)該開始改進(jìn)測試覆蓋率了. 注意, 實際的測試覆蓋率很難衡量 (而且往往趨近于 0%).

思考以下公有方法:

void setLength(double length);

調(diào)用 setLength(1.0)你可能會得到 100% 的執(zhí)行覆蓋率. 但要達(dá)到 100% 的實際測試覆蓋率, 有多少個 double 浮點數(shù)這個方法就必須被調(diào)用多少次, 并且要一一驗證行為的正確性. 這無疑是不可能的任務(wù).

16. 覆蓋邊界值

確保參數(shù)邊界值均被覆蓋. 對于數(shù)字, 測試負(fù)數(shù), 0, 正數(shù), 最小值, 最大值, NaN (非數(shù)字), 無窮大等. 對于字符串, 測試空字符串, 單字符, 非 ASCII 字符串, 多字節(jié)字符串等. 對于集合類型, 測試空, 1, 第一個, 最后一個等. 對于日期, 測試 1月1號, 2月29號, 12月31號等. 被測試的類本身也會暗示一些特定情況下的邊界值. 要點是盡可能徹底的測試這些邊界值, 因為它們都是主要 “疑犯”.

17. 提供一個隨機(jī)值生成器

當(dāng)邊界值都覆蓋了, 另一個能進(jìn)一步改善測試覆蓋率的簡單方法就是生成隨機(jī)參數(shù), 這樣每次執(zhí)行測試都會有不同的輸入.

想要做到這點, 需要提供一個用來生成基本類型 (如: 浮點數(shù), 整型, 字符串, 日期等) 隨機(jī)值的工具類. 生成器應(yīng)該覆蓋各種類型的所有取值范圍.

如果測試時間比較短, 可以考慮再裹上一層循環(huán), 覆蓋盡可能多的輸入組合. 下面的例子是驗證兩次轉(zhuǎn)換 little endian 和 big endian 字節(jié)序后是否返回原值. 由于測試過程很快, 可以讓它跑上個一百萬次.

void testByteSwapper()
{
  for (int i = 0; i < 1000000; i++) {
    double v0 = Random.getDouble();
    double v1 = ByteSwapper.swap(v0);
    double v2 = ByteSwapper.swap(v1);
    assertEquals(v0, v2);
  }
}

18. 每個特性只測一次

在測試模式下, 有時會情不自禁的濫用斷言. 這種做法會導(dǎo)致維護(hù)更困難, 需要極力避免. 僅對測試方法名指示的特性進(jìn)行明確測試.

因為對于一般性代碼而言, 保證測試代碼盡可能少是一個重要目標(biāo).

19. 使用顯式斷言

應(yīng)該總是優(yōu)先使用 assertEquals(a, b) 而不是 assertTrue(a == b), 因為前者會給出更有意義的測試失敗信息. 在事先不確定輸入值的情況下, 這條規(guī)則尤為重要, 比如之前使用隨機(jī)參數(shù)值組合的例子.

20. 提供反向測試

反向測試是指刻意編寫問題代碼, 來驗證魯棒性和能否正確的處理錯誤.

假設(shè)如下方法的參數(shù)如果傳進(jìn)去的是負(fù)數(shù), 會立馬拋出異常:

void setLength(double length) throws IllegalArgumentException

可以用下面的方法來測試這個特例是否被正確處理:

try {
  setLength(-1.0);
  fail();  // If we get here, something went wrong
}
catch (IllegalArgumentException exception) {
  // If we get here, all is fine
}

21. 代碼設(shè)計時謹(jǐn)記測試

編寫和維護(hù)單元測試的代價是很高的, 減少代碼中的公有接口和循環(huán)復(fù)雜度是降低成本, 使高覆蓋率測試代碼更易于編寫和維護(hù)的有效方法.

一些建議:

使類成員常量化, 在構(gòu)造函數(shù)中進(jìn)行初始化. 減少 setter 方法的數(shù)量.

限制過度使用繼承和公有虛函數(shù).

通過使用友元類 (C++) 或包作用域 (Java) 來減少公有接口.

避免不必要的邏輯分支.

在邏輯分支中編寫盡可能少的代碼.

在公有和私有接口中盡量多用異常和斷言驗證參數(shù)參數(shù)的有效性.

限制使用快捷函數(shù). 對于黑箱而言, 所有方法都必須一視同仁的進(jìn)行測試. 考慮以下簡短的例子:

public void scale(double x0, double y0, double scaleFactor)
{
  // scaling logic
}
 
public void scale(double x0, double y0)
{
  scale(x0, y0, 1.0);
}

刪除后者可以簡化測試, 但用戶代碼的工作量也將略微增加.

22. 不要訪問預(yù)設(shè)的外部資源

單元測試代碼不應(yīng)該假定外部的執(zhí)行環(huán)境, 以便在任何時候/任何地方都能執(zhí)行. 為了向測試提供必需的資源, 這些資源應(yīng)該由測試本身提供.

比如一個解析某類型文件的類, 可以把文件內(nèi)容嵌入到測試代碼里, 在測試的時候?qū)懭氲脚R時文件, 測試結(jié)束再刪除, 而不是從預(yù)定的地址直接讀取.

23. 權(quán)衡測試成本

不寫單元測試的代價很高, 但是寫單元測試的代價同樣很高. 要在這兩者之間做適當(dāng)?shù)臋?quán)衡, 如果用執(zhí)行覆蓋率來衡量, 業(yè)界標(biāo)準(zhǔn)通常在 80% 左右.

很典型的, 讀寫外部資源的錯誤處理和異常處理就很難達(dá)到百分百的執(zhí)行覆蓋率. 模擬數(shù)據(jù)庫在事務(wù)處理到一半時發(fā)生故障并不是辦不到, 但相對于進(jìn)行大范圍的代碼審查, 代價可能太大了.

24. 安排測試優(yōu)先次序

單元測試是典型的自底向上過程, 如果沒有足夠的資源測試一個系統(tǒng)的所有模塊, 就應(yīng)該先把重點放在較底層的模塊.

25. 測試代碼要考慮錯誤處理

考慮下面的這個例子:

Handle handle = manager.getHandle();
assertNotNull(handle);
 
String handleName = handle.getName();
assertEquals(handleName, "handle-01");

如果第一個斷言失敗, 后續(xù)語句會導(dǎo)致代碼崩潰, 剩下的測試都無法執(zhí)行. 任何時候都要為測試失敗做好準(zhǔn)備, 避免單個失敗的測試項中斷整個測試套件的執(zhí)行. 上面的例子可以重寫成:

Handle handle = manager.getHandle();
assertNotNull(handle);
if (handle == null) return;
 
String handleName = handle.getName();
assertEquals(handleName, "handle-01");

26. 寫測試用例重現(xiàn) bug

每上報一個 bug, 都要寫一個測試用例來重現(xiàn)這個 bug (即無法通過測試), 并用它作為成功修正代碼的檢驗標(biāo)準(zhǔn).

27. 了解局限

單元測試永遠(yuǎn)無法證明代碼的正確性!!

一個跑失敗的測試可能表明代碼有錯誤, 但一個跑成功的測試什么也證明不了.

單元測試最有效的使用場合是在一個較低的層級驗證并文檔化需求, 以及 回歸測試: 開發(fā)或重構(gòu)代碼時，不會破壞已有功能的正確性.

以下是一些良好的單元測試準(zhǔn)則：

1. 一個測試類只對應(yīng)一個被測類。當(dāng)前的測試類應(yīng)該與其他的測試類、環(huán)境設(shè)置等沒有任何依賴。

2. 測試類的目錄結(jié)構(gòu)和被測試類的對應(yīng)，這樣便于快速找到錯誤位置。

3. 一個測試方法只測試一個方法。同時，確保不要測試私有方法，它們是被封裝起來的，并不是API。

4. 測試用例的變量和方法都要有明確的含義。比如，將預(yù)期結(jié)果保存到 $expectedFoo 變量而不是只保存到 $foo。如果要測試很多復(fù)合結(jié)果，可使用組合變量名稱諸如：$inputValue_NotNull，$inputValue_ZeroData，$inputValue_PastDate等等（這要看你的代碼規(guī)范約定）。

5. 測試用例具備可讀性。測試用例代碼應(yīng)該遵循規(guī)范，像應(yīng)用代碼一樣易于理解。以后的維護(hù)者會在閱讀實現(xiàn)前去閱讀你的測試，這將幫助他們在調(diào)試前理解被測類的邏輯。

6. 測試用例干凈整潔。程序中不要有流程控制語句(switch，if 等)。一個好的測試用例處理順序簡單直接，準(zhǔn)備數(shù)據(jù)，驗證結(jié)果順序，如有必要，使用子方法分解結(jié)構(gòu)，讓測試用例更加易讀。如果是多場景，使用多個方法測試；例如，一個測試用例的方法代碼長度最多滿屏，不要有滾動條，大概在 1 到 20 行左右。如果測試代碼太長，考慮拆開成多個方法，以避免混在一起相互干擾；

7. 測試用例要驗證預(yù)期的異常。PHP中使用 @expectedException，不要忽略它們。

8. 測試用例不要連接數(shù)據(jù)庫。如果測試中需要連接數(shù)據(jù)庫，那么每個新的測試方法都應(yīng)自主引導(dǎo)到臨時數(shù)據(jù)庫（使用 Setup/Teardown做準(zhǔn)備）。如果不是必須連接數(shù)據(jù)庫，請使用mock產(chǎn)生確定的數(shù)據(jù)。

9. 測試用例不要連接網(wǎng)絡(luò)資源。測試某個方法時無法確保第三方的有效性，諸如網(wǎng)絡(luò)和設(shè)備的有效性，而應(yīng)該使用mocks代替。

10. 不要在自己的類中測試第三方的類庫。類庫應(yīng)該由它們自己的測試用例來測試，這也是我們選擇類庫的原因。如果它們自己沒有，應(yīng)該考慮使用mock來模擬類庫的輸出結(jié)果，確保輸入數(shù)據(jù)的確定性。我們不應(yīng)該在測試自己類功能的時候，還要考慮第三方庫的的功能。

11. 測試用例要處理好邊界情況，極限值 (max, min) 和null變量（即使拋異常）。你要確保這些問題狀況永遠(yuǎn)都不會發(fā)生，甚至在維護(hù)時不使用測試用例。

12. 測試用例在任何情況下都可運行，并且不需要配置和人工干預(yù)。

13. 測試用例通過當(dāng)前測試，并且易于改進(jìn)。測試用例要能夠支持代碼的演變，如果很難維護(hù)或者代碼太輕而不能細(xì)化，那就成了負(fù)擔(dān)（很多人不寫單元測試用例就是這個原因）。

14. 測試用例的輸入要具體。在PHP中，測試的方法不要使用 time()作為輸入，最好使用date_format()創(chuàng)建具體格式的時間。再如：name = "Smith"; 不要用 name = "name"或者 name = "test";

15. 測試用例不要使用@ignored或者被注釋掉，切記切記。

16. 測試用例幫忙驗證代碼架構(gòu)。如果你不能測試某個方法或者類，那么你的設(shè)計就不夠靈活。

17. 測試用例可以運行在任何平臺，而不僅是指定目標(biāo)平臺。不要指望一個特定設(shè)備或者硬件配置。不然你的測試用例會遷移困難，這樣會導(dǎo)致你會禁用他們。不應(yīng)該出現(xiàn)“在我的機(jī)器上沒問題啊”這種情況。

18. 測試用例運行速度快。慢的測試會把你拖垮，快的速度會鼓勵你經(jīng)常運行他們，它還能幫助你減少持續(xù)集成系統(tǒng)上的構(gòu)建時間。慎用delay() 或者 sleep() ，比如只有在某些邊緣情況下，比如等待通知或者基于時鐘的方法；

19. 把斷言從邏輯中分離出來。斷言應(yīng)該用來檢驗結(jié)果，不應(yīng)該執(zhí)行邏輯操作的。

20. 測試類不要包含私有的方法。私有方法都是一些具體的實現(xiàn)，不應(yīng)該包含在單元測試?yán)铩?/p>

21. 一個測試不要超過一個模擬(mock對象)。不然如何消除錯誤和不一致性。

22. 保持你的測試是冪等的。測試程序應(yīng)該能運行多次保持結(jié)果一致，不論運行一次還是一百萬次，它的效果都應(yīng)該是一樣的。并且，在測試過程中，我們不應(yīng)該改變?nèi)魏蔚臄?shù)據(jù)或者添加任何東西。

關(guān)于單元測試，網(wǎng)上多為描述具體實戰(zhàn)和其重要性，很少針對單元測試方式和原則做進(jìn)一步說明，而實際工作過程中很多開發(fā)者不知道應(yīng)該測試，Jean-baptiste Rieu寫了《Unit Testing Checklist: Keep Your Tests Useful and Avoid Big Mistakes》一文，他對單元測試中的原則和思想整理為一個checklist，相信對開發(fā)者有很大幫助。

1. 為何使用單元測試

它可以測試現(xiàn)有以及未來的功能模塊，保證了代碼質(zhì)量。它強(qiáng)制你書寫具有可測性，低耦合的代碼。這比手工回歸測試廉價的多。它將提高代碼可行度，協(xié)助團(tuán)隊工作。

2. 測試步驟

單元測試是驗證你代碼的一些常用方法集合。按照下面的步驟操作是個不錯的方法：

• 寫被測類的API；

• 寫一個方法測試API；

• 實現(xiàn)這個API；

• 執(zhí)行單元測試；

3. 測試原則（檢查清單）

為何需要個檢查清單？單元測試比實際實現(xiàn)可能還要難一些，它強(qiáng)迫你考慮清楚一些事情。但單元測試本身應(yīng)該簡單、直接、易用和易于維護(hù)。你還要知道何時停止寫測試并且開始寫實現(xiàn)。使用這個檢查清單能夠確保有效測試且達(dá)到目標(biāo)，該清單能幫你避免一些明顯的錯誤。

• 一個測試類只能對應(yīng)一個被測類。你要測試的是對應(yīng)類API的正確性，結(jié)果是所期望的。

• 每次只測試一個方法。確保不要測試私有方法，它們是被封裝起來的，并不是API。

• 測試用例的變量和方法都要有明確的含義。比如，將預(yù)期結(jié)果保存到 expectedFoo 變量而不是只保存到 foo。如果要測試很多復(fù)合結(jié)果，可使用組合變量名稱諸如：inputValue_NotNull, inputValue_ZeroData, inputValue_PastDate等等 (這要看你的代碼規(guī)范約定)。

• 測試用例易讀。以后的維護(hù)者會在閱讀實現(xiàn)前去閱讀你的測試，這將幫助他們在調(diào)試前理解被測類的邏輯。

• 測試用例干凈整潔。

• 程序中不要有流程控制語句(switch，if 等)。一個好的測試用例處理順序簡單直接，準(zhǔn)備數(shù)據(jù)，驗證結(jié)果順序，如有必要，使用子方法分解結(jié)構(gòu)，讓測試用例更加易讀。如果是多場景，使用多個方法測試；

• 例如，一個測試用例的方法代碼長度最多滿屏，不要有滾動條，大概在 1 到 20 行左右。如果測試代碼太長，考慮拆開成多個方法，以避免混在一起相互干擾；

• 測試用例要驗證預(yù)期的異常。Java中使用 @Test(expected=MyException.class)。

• 測試用例不要連接數(shù)據(jù)庫?；蛘哒f，如果測試中需要連接數(shù)據(jù)庫操作，必須使用mock，每個新的測試方法都自主引導(dǎo)到臨時數(shù)據(jù)庫（使用 Setup/Teardown做準(zhǔn)備）。

• 測試用例不要連接網(wǎng)絡(luò)資源。測試某個方法時無法確保第三方諸如網(wǎng)絡(luò)和設(shè)備的有效性 (使用mocks)。

• 測試用例要處理好邊界情況，極限值 (max, min) 和null變量（即使拋異常）。你要確保這些問題狀況永遠(yuǎn)都不會發(fā)生，甚至在維護(hù)時不使用測試用例。

• 測試用例在任何情況下都可運行，并且不需要配置和人工干預(yù)。

• 測試用例通過當(dāng)前測試，并且易于改進(jìn)。測試用例要能夠支持代碼的演變，如果很難維護(hù)或者代碼太輕而不能細(xì)化，那就成了負(fù)擔(dān)（很多人不寫單元測試用例就是這個原因）。

• 測試用例要具體。在Java中，測試的方法不要使用 Date()作為輸入，最好使用Calendar創(chuàng)建具體格式的時間（別忘了設(shè)置時區(qū)）。再如：name = “Smith”; 不要用 name = “name”或者 name = “test”;

• 測試用例使用mock來模擬復(fù)雜的類結(jié)構(gòu)或方法。

• 記住一次只測試一個類；

• 不要在自己的類中測試第三方的類庫. 類庫應(yīng)該由它們自己的測試用例來測試（這也是選擇選擇類庫的一個好方式）；

• 測試用例不要使用@ignored或者被注釋掉，切記切記。

• 測試用例幫我驗證了代碼架構(gòu)。如果你不能測試某個方法或者類，那么你的設(shè)計就不夠靈活。

• 測試用例可以運行在任何平臺，而不僅是指定目標(biāo)平臺。不要指望一個特定設(shè)備或者硬件配置。不然你的測試用例會遷移困難，這樣會導(dǎo)致你會禁用他們。

• 測試用例運行速度快。

• 慢的測試會把你拖垮，快的速度會鼓勵你經(jīng)常運行他們，它還能幫助你減少持續(xù)集成系統(tǒng)上的構(gòu)建時間；

• 使用測試運行程序時允許你一次啟動一個測試。慎用“delay” 或者 “sleep” ，比如只有在某些邊緣情況下，比如等待通知或者基于時鐘的方法；

• 單元測試