一、測試準則
必須滿足AIR原則
A：Automatic（自動化）
I：Independent（獨立性）
R：Repeatable（可重複）
可參照27條準則。
引用連結：https://blog.csdn.net/neo_ustc/article/details/22612759
原文連結：https://petroware.no/unittesting.html
如下：
27條準則
- 保持單元測試小巧, 快速
- 單元測試應該是全自動/非互動式的
- 讓單元測試很容易跑起來
- 對測試進行評估
- 立即修正失敗的測試
- 把測試維持在單元級別
- 由簡入繁
- 保持測試的獨立性
- Keep tests close to the class being tested
- 合理的命名測試用例
- 只測試公有介面
- 看成是黑盒
- 看成是白盒
- 芝麻函式也要測試
- 先關注執行覆蓋率
- 覆蓋邊界值
- 提供一個隨機值生成器
- 每個特性只測一次
- 使用顯式斷言
- 提供反向測試
- 程式碼設計時謹記測試
- 不要訪問預定的外部資源
- 權衡測試成本
- 合理安排測試優先次序
- 為測試失敗做好準備
- 寫測試用例重現 bug
瞭解侷限
二、目錄結構規範：
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）規範命名。
2.js和ts檔案依照短橫線（kabab-case）規範命名，Vue檔案依照駝峰（camelCased）規範命名。
3.每個原始碼檔案（如js，ts，vue）對應一個同名.test.js檔案。（index檔案可以忽略）
三、編碼原則
必須符合 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
單元測試在最近的工作中使用比較廣泛，我已經收集了一些關於如何編寫更好的測試類的準則，並且我已經嘗試著堅持這些準則多年了。記住，編寫糟糕的測試是在浪費時間，並會在以後造成更大的問題。所以最好把這些準則記在心裡。
1.不應該編寫成功通過的單元測試-它們應該被寫成不通過的。
可以在幾分鐘內讓任何一組測試通過，但這只是在欺騙你自己。
2.測試類應該只測試一個功能。
你應該用一個功能去測試一個方法。否則，你會違反了單一職責原則。
3.測試類具備可讀性。
確保測試類標有註釋並且容易理解，就像其他的程式碼一樣。
4.良好的命名規範。
再次測試時應該像其他程式碼一樣-便於人們理解。
5.把斷言從行為中分離出來。
你的斷言應該用來檢驗結果，而不是執行邏輯操作的。
6.使用具體的輸入。
不要使用任何的自動化測試資料來輸入，像date()這些產生的資料會引入差異。
7.把測試類分類，放在不同的地方。
從邏輯的角度看，當沒有錯誤指向特定的問題時這更容易去查詢。
8.好的測試都是一些獨立的測試類。
你應該讓測試類與其他的測試、環境設定等沒有任何依賴。這利於建立多個測試點。
9.不要包含私有的方法。
他們都是一些具體的實現，不應該包含在單元測試裡。
10.不要連線資料庫或者資料來源。
這是不靠譜的。因為你不能確保資料服務總是一樣的並且能夠建立測試點。
11.一個測試不要超過一個模擬(mock物件)。
我們努力去消除錯誤和不一致性。
12.單元測試不是整合測試。
如果你想測試結果，不要使用單元測試。
13.測試必須具有確定性。
你需要一個確定的預測結果，所以，如果有時候測試通過了，但是不意味著完成測試了。
14.保持你的測試是冪等的。
你應該能夠執行你的測試多次而不改變它的輸出結果，並且測試也不應該改變任何的資料或者新增任何東西。無論是執行一次還是一百萬次，它的效果都應該是一樣的。
15.測試類一次僅測試一個類，測試方法一次僅測試一個方法。
組織方法能夠在問題出現時檢測出來，並幫你確定測試依賴。
16.在你的測試裡使用異常。
你在測試裡會遇到異常，所以，請不要忽略它，要使用它。
17.不要使用你自己的測試類去測試第三方庫的功能。
大多數好的庫都應該有它們自己的測試，如果沒考慮用mocks去產生一致性的結果的話。
18.限制規則。
當在一些規則下寫測試時，記住你的限制和它們（最小和最大）設定成最大的一致性。
19測試類不應該需要配置或者自定義安裝。
你的測試類應該能夠給任何人使用並且使它執行。“在我的機器上執行”不應該出現在這。
四、編碼規範：
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.測試用例的變數和方法都要有明確的含義
五、測試維度
編寫單元測試，主要參考以下幾個方面：
來源連結：
1.介面功能性測試
介面功能的正確性,即保證介面能夠被正常呼叫，並輸出有效資料!
------------------> 是否被順利呼叫
------------------> 引數是否符合預期
2.區域性資料結構測試
保證資料結構的正確性
------------------> 變數是否有初始值或在某場景下是否有預設值
------------------> 變數是否溢位
3.邊界條件測試
------------------> 變數無賦值(null)
------------------> 變數是數值或字元
------------------> 主要邊界：最大值，最小值，無窮大
------------------> 溢位邊界：在邊界外面取值+/-1
------------------> 臨近邊界：在邊界值之內取值+/-1
------------------> 字串的邊界，引用 "變數字元"的邊界
------------------> 字串的設定，空字串
------------------> 字串的應用長度測試
------------------> 空白集合
------------------> 目標集合的型別和應用邊界
------------------> 集合的次序
------------------> 變數是規律的，測試無窮大的極限，無窮小的極限
4.所有獨立程式碼測試
保證每一句程式碼，所有分支都測試完成，主要包括程式碼覆蓋率，異常處理通路測試
------------------> 語句覆蓋率：每個語句都執行到了
------------------> 判定覆蓋率：每個分支都執行到了
------------------> 條件覆蓋率：每個條件都返回布林
------------------> 路徑覆蓋率：每個路徑都覆蓋到了
5.異常模組測試
後續處理模組測試:是否包閉當前異常或者對異常形成消化,是否影響結果!
六、測試目標
說明：以下僅作為參考，實際還需要按照各自專案進行評估。
語句覆蓋率：>=70%
分支覆蓋率：100%
函式覆蓋率：100%
行覆蓋率： 80%
!18 !!#ff0000 執行覆蓋率, 業界標準通常在 80% 左右!!!