2023年Q2用戶偏好榜：12+256G版本成新主流
3月份的性能榜、性價比榜和好評榜之后，就要輪到2023年的第二季度偏好榜了，上半年的新機潮已經過去，最明顯的肯定就是大內存和存儲的機型了，另外部分中端機也取消了屏幕塑料支架
這是一個關于 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 會很順利。在過去的幾年里，我看到人們一直在拋棄從 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
本文鏈接：http://www.www897cc.com/showinfo-26-79988-0.html放棄 Jest 后，運行時間減少 90%！
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 球盒模型：一切回溯窮舉，皆從此法出
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號