一、測試准則
必須滿足AIR原則
A：Automatic（自動化）
I：Independent（獨立性）
R：Repeatable（可重復）
可參照27條准則。
引用鏈接：https://blog.csdn.net/neo_ustc/article/details/22612759
原文鏈接：https://petroware.no/unittesting.html
如下：
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. 了解局限
二、結構規范
目錄結構規范：
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文件可以忽略）
三、編碼原則
必須符合 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.測試用例的變量和方法都要有明確的含義
五、測試維度
編寫單元測試，主要參考以下幾個方面：
來源鏈接：https://blog.csdn.net/qq_36505948/article/details/82797240
1.接口功能性測試
接口功能的正確性,即保證接口能夠被正常調用，並輸出有效數據!
====> 是否被順利調用
====> 參數是否符合預期
2.局部數據結構測試
保證數據結構的正確性
====> 變量是否有初始值或在某場景下是否有默認值
====> 變量是否溢出
3.邊界條件測試
====> 變量無賦值(null)
====> 變量是數值或字符
====> 主要邊界：最大值，最小值，無窮大
====> 溢出邊界：在邊界外面取值+/-1
====> 臨近邊界：在邊界值之內取值+/-1
====> 字符串的邊界，引用 "變量字符"的邊界
====> 字符串的設置，空字符串
====> 字符串的應用長度測試
====> 空白集合
====> 目標集合的類型和應用邊界
====> 集合的次序
====> 變量是規律的，測試無窮大的極限，無窮小的極限
4.所有獨立代碼測試
保證每一句代碼，所有分支都測試完成，主要包括代碼覆蓋率，異常處理通路測試
====> 語句覆蓋率：每個語句都執行到了
====> 判定覆蓋率：每個分支都執行到了
====> 條件覆蓋率：每個條件都返回布爾
====> 路徑覆蓋率：每個路徑都覆蓋到了
5.異常模塊測試
后續處理模塊測試:是否包閉當前異常或者對異常形成消化,是否影響結果!
六、測試目標
說明：以下僅作為參考，實際還需要按照各自項目進行評估。
語句覆蓋率：>=70%
分支覆蓋率：100%
函數覆蓋率：100%
行覆蓋率： >=80%
執行覆蓋率, 業界標准通常在 80% 左右!!