我在 DOM 測驗和組件類測驗之間進行選擇。遇到了一些問題，希望你能幫助我。
- 優點和缺點在某種程度上對我來說很清楚，但我注意到 Github 中幾乎所有的庫都使用 DOM 測驗，這背后是否有原因：D？
- 通過 DOM 測驗，是否有可能獲得 html 覆寫（類似于 Karma/Istanbul 的代碼覆寫）？
- 有人提到，在 DOM 測驗的情況下，我正在測驗一個場景而不是代碼，對嗎，如果是的話，這會如何影響我的期望（何時對我的測驗感到滿意）
- 在代碼審查中，您會尋找什么（除了代碼覆寫率）來確保添加的新內容經過完全測驗？
提前致謝 ：）。
uj5u.com熱心網友回復：
在測驗前端時，理想情況下，您希望測驗最終用戶將體驗到什么。所以作為回應：
優點和缺點在某種程度上對我來說很清楚，但我注意到 Github 中幾乎所有的庫都使用 DOM 測驗，這背后是否有原因：D？
DOM 測驗允許您測驗互動，這可能是大多數庫這樣做的原因。它確保最終用戶的互動執行預期的操作。
通過 DOM 測驗，是否有可能獲得 html 覆寫（類似于 Karma/Istanbul 的代碼覆寫）？
我認為沒有像 Karma/Istanbul 這樣的可比較的“HTML 覆寫率”報告，我不知道它是否可行/有幫助。在測驗 Angular 組件時，整個組件都在測驗瀏覽器中呈現——因此對于呈現或測驗了多少 HTML 而言，不會有一個非常有用的指標。
有人提到，在 DOM 測驗的情況下，我正在測驗一個場景而不是代碼，對嗎，如果是的話，這會如何影響我的期望（何時對我的測驗感到滿意）
是的 - 您正在測驗場景和與 DOM 測驗的互動。您設定用戶可能遇到的場景并測驗用戶在該場景中可以訪問哪些操作。
在代碼審查中，您會尋找什么（除了代碼覆寫率）來確保添加的新內容經過完全測驗？
只要您確保您的測驗有用并提供價值（它們正確評估用戶的互動是否達到預期目標），您的代碼覆寫率就足夠了。除了組件、服務、指令等單元測驗（我的建議）之外，您還可以使用Cypress等框架查看 E2E 測驗。
測驗 Angular是了解如何在 Angular 中進行測驗的重要資源。例如，它建議不要直接在組件上測驗內部和私有方法，而是對組件的 API 進行單元測驗——輸入、輸出、點擊等隱式測驗這些內部和私有方法。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qianduan/468154.html