這是一個關于 Jest 在 JS 服務端的經驗分享，注意，不是 UI 測試。如果你對 Jest 感到滿意，請不要切換！這不是為了說服任何人。

Jest 是個眾所周知的、功能完備的測試框架，曾經在選擇時并沒有經過深思熟慮。然而，經過數百次測試后，情況開始變得很糟糕。內存泄漏開始浮出水面，臨時的標志位數量增多，經常訪問 Jest 的 issues 標簽頁已經成為家常便飯。

問題

以下是作者曾在 Jest 中遇到的一些問題，通過這些標志可以幫助排插問題或提高部分的性能，如果你在使用 Jest，可以做為一個參考。

• jest —logHeapUsage：監視堆使內存用情況，以發現突然增長的內存泄漏。
• jest —maxWorkers=50%：一些基準測試顯示，該配置可使測試運行速度提高 20%，也有些人說這會變得更糟。
• jest —runInBand: 這在當前進程中串行運行所有測試，而不是創建一個子進程的工作池。有人說這對于調試很有用，但奇怪的是，一些人報告說它實際上可以提高性能。
• jest —changedSince：該標志可以顯著減少 PR 工作流程所需的時間。
• jest-slow-test-reporter：這個報告器可以發現你項目中最慢的測試。
• --expose-gc：暴露 Node.js 的垃圾收集器。某些情況下，使用 --expose-gc 標志運行 Node 似乎能更好地處理內存泄漏。

不夠好

這些策略中的一些在這段時間內顯著減少了運行時間。然而，學習和實施它們的過程是以交付時間為代價的，而這實際上更為關鍵。

測試是如此緩慢，以至于我只在我們當前正在開發的模塊上運行它們，然后只在PR中更改的模塊上運行它們，最后，所有的測試只有在合并到主分支時才會運行。不幸的是，這種方法導致了識別錯誤的延遲。

測試如此耗時，以至于我發現自己在為某些功能猶豫是否編寫測試，擔心它們會導致額外的構建過程時間。在這一點上，我意識到是時候轉變了

切換到 Mocha

我十年前用過 Mocha，感覺非常棒。所以，我以為回到 Mocha 會很順利。在過去的幾年里，我看到人們一直在拋棄從 Jest 到 Mocha 的想法，而我總是覺得很有趣。我記得有很多指南和人們在談論從 Mocha 遷移到 Jest。像我一樣，大多數人會認為更新的工具會有更好或者至少類似的性能。

遷移比預期的要容易得多。幾個替換案例，少于一個小時的重構一些代碼。比較困難的部分是模擬引擎，這在 Mocha 中沒有包含。

我本來可以使用 Sinon.js 來做到這一點，但我真的很喜歡有一天不依賴任何測試庫的想法。我甚至考慮過只使用新的 Node.js 內置測試運行器，但對我來說它還不夠完善。所以，我決定只使用內置的 MockTracker。

嘗試后讓人驚訝。使用 Jest 運行需要3秒的單個測試，在 Mocha 中只需要不到 200ms。這應該不足為奇——我運行的測試不應該花費那么長時間，但我已經習慣了那種緩慢。最終，我們的測試運行時間從超過 12 分鐘縮短到不到 40 秒。

Mocha 的速度幫助我們發現了隱藏的錯誤，這些錯誤偶爾會導致測試失敗，因為它們只在非常特殊的條件下發生——這些條件在 Jest 中由于其較慢

結論

我仍然在我維護的一些較小的代碼庫中使用 Jest，并且除非它們成為問題，否則我不會瘋狂地遷移它們。然而，對于未來的項目，我肯定會選擇 Mocha 或 Node.js 測試運行器。

問題在于，即使有一種方法可以優化 Jest 并在合理的時間內運行數千個測試，但僅僅切換測試框架就能顯著提高性能，這是有問題的。你同意嗎？你有類似的經歷嗎？我很樂意聽聽。

作者 | Patrickrbc翻譯、整理 | 五月君原文 https://patrickrbc.com/2024/03/16/jest-slow-tests