單元測試的規範

1、測試準則

必須知足AIR原則

A：Automatic（自動化）
I：Independent（獨立性）
R：Repeatable（可重複）

可參照27條準則。
引用連接：https://blog.csdn.net/neo_ustc/article/details/22612759
原文連接：https://petroware.no/unittesting.html
以下：

27條準則

   
  1. 保持單元測試小巧, 快速
2. 單元測試應該是全自動/非交互式的
3. 讓單元測試很容易跑起來
4. 對測試進行評估
5. 當即修正失敗的測試
6. 把測試維持在單元級別
7. 由簡入繁
8. 保持測試的獨立性
9. Keep tests close to the class being tested
10. 合理的命名測試用例
11. 只測試公有接口
12. 當作是黑盒
13. 當作是白盒
14. 芝麻函數也要測試
15. 先關注執行覆蓋率
16. 覆蓋邊界值
17. 提供一個隨機值生成器
18. 每一個特性只測一次
19. 使用顯式斷言
20. 提供反向測試
21. 代碼設計時謹記測試
22. 不要訪問預約的外部資源
23. 權衡測試成本
24. 合理安排測試優先次序
25. 爲測試失敗作好準備
26. 寫測試用例重現 bug
27. 瞭解侷限

2、結構規範

目錄結構規範：

1.源碼存放在src目錄，每一個功能模塊建立單個npm包
2.src同級建立test/unit做爲單元測試文件目錄
3.test/unit目錄下建立源npm包同名文件夾，用於存放單元測試文件
4.src同級建立test/integration做爲集成測試文件夾
5.test/integration目錄下建立源npm包同名文件夾，用於存放集成測試文件

文件命名規範：

1.test目錄下測試文件名同源碼文件名同名，後綴以.test.js結尾
2.test/unit和test/integration建立測試文件夾時，參照短橫線（kabab-case）規範命名。
3.js和ts文件依照短橫線（kabab-case）規範命名，Vue文件依照駝峯（camelCased）規範命名。
4.每一個源碼文件（如js，ts，vue）對應一個同名.test.js文件。（index文件能夠忽略）

3、編碼原則

必須符合 BCDE 原則：

B：Border，邊界值測試，包括循環邊界、特殊取值、特殊時間點、數據順序等。
C：Correct，正確的輸入，並獲得預期的結果。
D：Design，與設計文檔相結合，來編寫單元測試。
E：Error，強制錯誤信息輸入（如：非法數據、異常流程、非業務容許輸入等），並獲得預期的結果。

避免如下狀況：

1）構造方法中作的事情過多。
2）存在過多的全局變量和靜態方法。
3）存在過多的外部依賴。
4）存在過多的條件語句。

建議：

1.涉及到的某些擴展模塊可使用mock模擬
2.測試用例不要使用@ignored或者被註釋掉，切記切記。

如何編寫更好的單元測試

原文連接：https://www.techug.com/post/19-unit-test-code-tips.html
單元測試在最近的工做中使用比較普遍，我已經收集了一些關於如何編寫更好的測試類的準則，而且我已經嘗試着堅持這些準則多年了。記住，編寫糟糕的測試是在浪費時間，並會在之後形成更大的問題。因此最好把這些準則記在內心。

19條建議

1.不該該編寫成功經過的單元測試-它們應該被寫成不經過的。

能夠在幾分鐘內讓任何一組測試經過，但這只是在欺騙你本身。

2.測試類應該只測試一個功能。

你應該用一個功能去測試一個方法。不然，你會違反了單一職責原則。

3.測試類具有可讀性。

確保測試類標有註釋而且容易理解，就像其餘的代碼同樣。

4.良好的命名規範。

再次測試時應該像其餘代碼同樣-便於人們理解。

5.把斷言從行爲中分離出來。

你的斷言應該用來檢驗結果，而不是執行邏輯操做的。

6.使用具體的輸入。

不要使用任何的自動化測試數據來輸入，像date()這些產生的數據會引入差別。

7.把測試類分類，放在不一樣的地方。

從邏輯的角度看，當沒有錯誤指向特定的問題時這更容易去查找。

8.好的測試都是一些獨立的測試類。

你應該讓測試類與其餘的測試、環境設置等沒有任何依賴。這利於建立多個測試點。

9.不要包含私有的方法。

他們都是一些具體的實現，不該該包含在單元測試裏。

10.不要鏈接數據庫或者數據源。

這是不靠譜的。由於你不能確保數據服務老是同樣的而且可以建立測試點。

11.一個測試不要超過一個模擬(mock對象)。

咱們努力去消除錯誤和不一致性。

12.單元測試不是集成測試。

若是你想測試結果，不要使用單元測試。

13.測試必須具備肯定性。

你須要一個肯定的預測結果，因此，若是有時候測試經過了，可是不意味着完成測試了。

14.保持你的測試是冪等的。

你應該可以運行你的測試屢次而不改變它的輸出結果，而且測試也不該該改變任何的數據或者添加任何東西。不管是運行一次仍是一百萬次，它的效果都應該是同樣的。

15.測試類一次僅測試一個類，測試方法一次僅測試一個方法。

組織方法可以在問題出現時檢測出來，並幫你肯定測試依賴。

16.在你的測試裏使用異常。

你在測試裏會遇到異常，因此，請不要忽略它，要使用它。

17.不要使用你本身的測試類去測試第三方庫的功能。

大多數好的庫都應該有它們本身的測試，若是沒考慮用mocks去產生一致性的結果的話。

18.限制規則。

當在一些規則下寫測試時，記住你的限制和它們（最小和最大）設置成最大的一致性。

19.測試類不該該須要配置或者自定義安裝。

你的測試類應該可以給任何人使用而且使它運行。「在個人機器上運行」不該該出如今這。

4、編碼規範：

1.test對應每一個源碼建立單元測試包

2.每一個npm包，都要添加descript,描述名爲npm包名。

如descript("awp-lib-moment",()=>{});

3.需生成快照文件的單元測試，快照須要每次提交。

4.expect test('') 中描述的是調用和指望輸出結果。

如test("Moment.format('yyyyMMdd HH:mm:ss','2019/07/09 17:41:01') 指望輸出結果：20190709 17:41:01", () => {});

5.進行參數或屬性校驗。

校驗包含正向和反向校驗，即正確類型正確輸出和異常類型返回異常信息等。
校驗種類包含，參數個數、參數類型等。

6.測試要覆蓋實現中的代碼的各個分支

7.一個測試方法只測試一個方法，不測試私有方法

8.一個測試類只對應一個被測類.

9.測試用例的變量和方法都要有明確的含義

5、測試維度

編寫單元測試，主要參考如下幾個方面：
來源連接：https://blog.csdn.net/qq_36505948/article/details/82797240

1.接口功能性測試

接口功能的正確性,即保證接口可以被正常調用，並輸出有效數據!
------------------> 是否被順利調用
------------------> 參數是否符合預期

2.局部數據結構測試

保證數據結構的正確性
------------------> 變量是否有初始值或在某場景下是否有默認值
------------------> 變量是否溢出

3.邊界條件測試

------------------> 變量無賦值(null)
------------------> 變量是數值或字符
------------------> 主要邊界：最大值，最小值，無窮大
------------------> 溢出邊界：在邊界外面取值+/-1
------------------> 臨近邊界：在邊界值以內取值+/-1
------------------> 字符串的邊界，引用 "變量字符"的邊界
------------------> 字符串的設置，空字符串
------------------> 字符串的應用長度測試
------------------> 空白集合
------------------> 目標集合的類型和應用邊界
------------------> 集合的次序
------------------> 變量是規律的，測試無窮大的極限，無窮小的極限

4.全部獨立代碼測試

保證每一句代碼，全部分支都測試完成，主要包括代碼覆蓋率，異常處理通路測試
------------------> 語句覆蓋率：每一個語句都執行到了
------------------> 斷定覆蓋率：每一個分支都執行到了
------------------> 條件覆蓋率：每一個條件都返回布爾
------------------> 路徑覆蓋率：每一個路徑都覆蓋到了

5.異常模塊測試

後續處理模塊測試:是否包閉當前異常或者對異常造成消化,是否影響結果!

6、測試目標

說明：如下僅做爲參考，實際還須要按照各自項目進行評估。

語句覆蓋率：>=70%

分支覆蓋率：100%

函數覆蓋率：100%

行覆蓋率： >=80%

執行覆蓋率, 業界標準一般在 80% 左右!!