測試框架千千萬，我偏愛 vitest
前端測試框架千千萬，jest、vitest、Jasmine、mocha等等，但我個人更偏愛 vitest，簡潔，高效，現代化，這篇文章就帶大家了解一下關于vitest的一些知識和特性，幫助大家更好的使用vitest。
why vitest
Vitest 由核心Vite團隊成員Anthony fu（一個托尼）開發，它建立在Vite之上，但非vite項目其實也可以使用vitest。而vite想必大家都非常熟悉了，它可以快速的啟動開發服務器，利用瀏覽器的ES模塊系統，從而加快本地開發速度，這讓vite變得十分受歡迎。
雖然用vite開發的項目也可以和jest一起使用，但是vite和jest中其實有很多配置重復的部分，迫使用戶要維護和運行兩套流程。
所以，vitest一開始要解決的問題就是便于在vite項目中方便集成測試能力；在開發中，將Vitest與Vite結合使用的主要優勢是他們都有很好的性能，方便一起集成，以及他們都共享配置同一份配置。
vite的爆火一定程度上也讓vitest增加了曝光度，它也在社區中十分受歡迎，成為了越來越多測試框架的首選：
Vitest 對比 jest
說到vitest，不得不提另外一個測試框架也就是jest。
早在2011年，還沒有JavaScript測試框架能滿足Facebook（meta）團隊的測試需求，所以他們創建了Jest。Jest在2014年開源，就在React開源后不久，jest也隨著React迅速流行起來。2016年，jest成為create react APP(CRA)命令創建react應用的首選測試框架，Next.js V12版本也把jest作為默認測試框架，jest主流地位已然確立。
2022年，jest所有權已經轉移給OpenJS基金會，由meta外部人員維護，之后jest的更新和維護就變得相對緩慢。jest的最新一次更新版本在1年前，jest的v30版本早在2023年就已經發布alpha版本，但是現在已經2025年了，v30版本仍然沒有發布；但是vitest去年就從v1版本更新到了v3版本......
vitest對比jest一個顯著的優勢是vitest原生支持typescript、ESM，而jest v29版本現在對于ESM的支持還是實驗性的，此外如果要支持typescript還需要配置babel，通過babel來轉譯支持typescript。而vitest對于現代特性都是開箱即用的。
關于性能方面，在redit論壇 (https://www.reddit.com/r/reactjs/comments/10zyse3/is_jest_still_faster_than_vitest/)上有很多關于jest和vitest的性能測試的討論，有的反饋說jest比較快，有的說vitest比較快。但不管怎么樣，vitest的HMR特性是要比jest是要快的，也就是開發過程中只運行修改文件的測試。原因是vitest是基于修改模塊的依賴樹去做的分析重新運行，而jest是基于git未提交代碼做的分析，這可能不太準確，因為并非所有檢測到的更改文件都與現在運行的測試相關。
下面是關于jest和vitest特性的一個全面對比：
vitest有更多的現代特性，以及vitest處于一個快速迭代社區逐漸繁榮的階段，如果是一個使用現代特性的新項目，那么vitest肯定是首選！
vitest的一些特性
關于怎么開始和配置，比較簡單，本文就不展開了，下面詳細聊聊vitest的一些特性，了解完這些特性后，想必你對vitest有更全面的認識。
兼容jest API 但是更強
因為jest的API已經設計的比較優秀（從他的下載占有率可以看出），vitest幾乎完全兼容了jest的API設置。比如Expect、Mock、Setup and TearDown等API。所以從jest項目遷移到vitest只需要做很少的調整，具體可以參考官方文檔（https://vitest.dev/guide/migration.html#jest），其中一個都會遇到的調整是globals的配置，他可以不用引入vitest，也能使用全局API。
此外，vitest的v3 API增加了更多的能力，比如toHaveBeenCalledExactlyOnceWith，他可以檢測某個函數只被調用了一次且調用參數為預期值。
test('vitest mocking example', () => {
const mock = vi.fn();
mock('hello');
// New matcher for more precise assertions
expect(mock).toHaveBeenCalledExactlyOnceWith('hello');
// Spy reuse example
const obj = {
method: () => {}
};
const spy = vi.spyOn(obj, 'method');
// Spy is automatically reused if spyOn is called again
const sameSpy = vi.spyOn(obj, 'method');
expect(spy === sameSpy).toBe(true);
});默認watch模式
在jest中，我們要使用watch模式的時候，需要增加--watch參數(即jest --watch)；但是vitest默認使用watch模式（即vitest)，不需要增加--watch參數，也能自動進入watch模式。
但是如果是CI環境，我們運行watch模式，是不是不符合預期？
vitest會根據是否有環境變量process.env.CI判斷是否處于CI環境，如果有環境變量則不會啟動watch模式。
當然也可以通過指定--watch參數以及--run參數，來指定watch模式還是單次運行。
源碼內聯測試
什么是源碼內聯測試（In-Source Testing）呢？
這是一個rust模塊測試的方式，他可以讓我們把測試代碼寫在源碼中。
這可以讓測試代碼和源碼代碼使用相同的閉包環境，關注的邏輯和代碼在同一地方，這可以讓我們更快速的發現問題、修復問題，每次代碼修改后都能立即運行測試代碼并進行修復，便于維護；但是由于測試代碼和源代碼在一個文件里，非常容易耦合，所以對代碼質量有一定要求。
下面是一個內聯代碼測試的demo：
export function add(...args: number[]) {
return args.reduce((a, b) => a + b, 0)
}
// in-source test suites
if (import.meta.vitest) {
const { it, expect } = import.meta.vitest
it('add', () => {
expect(add()).toBe(0)
expect(add(1)).toBe(1)
expect(add(1, 2, 3)).toBe(6)
})
}官方建議對更復雜的測試使用單獨的測試文件，源代碼內測試適用于對小函數進行單元測試和原型設計，因此對于為 JavaScript 庫編寫測試特別有用。
此外，如果我們在生產環境使用該模式，應該為bundler增加變量定義，以便于bundler分析dead code并刪除：
import { defineConfig } from 'vitest/config'
export default defineConfig({
test: {
includeSource: ['src/**/*.{js,ts}'],
},
define: {
'import.meta.vitest': 'undefined',
},
})真正的瀏覽器測試
在vitest v2版本引入了瀏覽器模式，該模式還處于實驗階段。該模式將在瀏覽器環境直接運行代碼，所以他可以訪問真正的dom API，所以理論上在實際環境中運行的測試將會更加可靠。缺點就是慢！
在node環境的測試中，我們一般通過js-dom或者happy-dom來模擬瀏覽器環境，happy-dom支持更少的瀏覽器API，但是更快，js-dom則相反。我們可以根據需要選擇不同的dom模擬環境，vitest同時支持js-dom和happy-dom。
vitest支持在不同的容器運行測試，比如playwright或者webdriverio ，這兩者比較顯著的差異是他們底層協議不同，playwright使用的Chrome DevTools 協議，而webdriverio使用的是WebDriver 協議：
vitest提供了開箱即用的包來渲染常用的前端框架的組件，下面是一個react的demo：
import { expect, test } from'vitest'
import { render } from'vitest-browser-react'
import HelloWorld from'../src/HelloWorld'
test('renders name', async () => {
const { getByText, getByRole } = render(<HelloWorld name="Vitest" />)
await expect.element(getByText('Hello Vitest x1!')).toBeInTheDocument()
await getByRole('button', { name: 'Increment '}).click()
await expect.element(getByText('Hello Vitest x2!')).toBeInTheDocument()
})可以看到API和用法幾乎和@testing-library/react幾乎相同，相同的代碼可以讓運行環境切換到瀏覽器環境！
其他的特性
- Browber UI。直接啟動一個前端頁面，在這個頁面中可以更好的調試、運行、修復測試；
- 類型測試。提供類型斷言的API可以對TS的類型進行測試；
- 提供benchmark
- workspace配置。v3版本的vitest增加了workspace配置，它特別適用于monorepo，可以在一個配置文件里配置多個項目的配置。
- ...
這里就不一一列舉了，感興趣的小伙伴建議直接查看官網。
一些技巧
下面分享個人在使用vitest的過程中的一些有用的技巧。
使用vscode的debug terminal
這是一個node調試比較通用的技巧，對于vitest同樣適用。使用vscode 的debug terminal可以非常方便的查看變量的參數，這非常適合我們在mock出現問題的時候debug。
使用skip或者only來快速調試
在調試單元測試的時候，我們經常會遇到單測報錯，但是可能因為mock或者一些上下文影響，十分難以調試，這個時候可能會用到skip和only API，這兩個API可以只運行某個case或者跳過某個case，可以減少影響面，幫助我們快速調試（而不是注釋代碼）
it.only('should be open', () => {
//...
});
it.skip('should be closed', () => {
//...
});優雅的retry
vitest中有很多重試的方法，比如：
import { expect, test } from"vitest";
import { sum } from"./sum.js";
it(
"adds 1 + 2 to equal 3",
{
retry: 3,
timeout: 3000,
},
() => {
expect(sum(1, 2)).matchSnapshot();
}
);it支持傳入第二個配置參數，該參數可以配置retry和timeout等，可以針對一整個case retry的場景。
此外，vitest還支持waifor API，該API可以不斷嘗試和獲取API：
// @vitest-environment jsdom
import { expect, test, vi } from'vitest'
import { getDOMElementAsync, populateDOMAsync } from'./dom.js'
test('Element exists in a DOM', async () => {
// start populating DOM
populateDOMAsync()
const element = await vi.waitFor(async () => {
// try to get the element until it exists
const element = await getDOMElementAsync() as HTMLElement | null
expect(element).toBeTruthy()
expect(element.dataset.initialized).toBeTruthy()
return element
}, {
timeout: 500, // default is 1000
interval: 20, // default is 50
})
expect(element).toBeInstanceOf(HTMLElement)
})上面這個case會在dom真正渲染出來，才會執行下面的語句，之前會一直輪詢執行語句，判斷是否正確執行。
另外，@testing-library/react里面也有很多類似的API底層其實就是使用waitfor，例如findAllByTextAPI，該API會等待元素渲染完成之后，再繼續進行下面的代碼。
Bad case：
使用盡量詳細的斷言
我遇到一些單測的case，因為沒有運行每個case前mockReset，導致之前spy函數調用記錄仍然存在，于是好幾個case在不同的測試場景中，相同的斷言均是toHaveBeenCalledWith，該斷言因為只會判斷歷史調用中是否存在某參數調用就行了，所以導致這幾個case均成功了，但是實際上是有問題的。
我們應該使用更加詳細的斷言，比如toHaveBeenNthCalledWith或者上文提到的toHaveBeenCalledExactlyOnceWith。
總結
vitest能夠快速火起來，我認為其原因有三點。首先提供了和jest兼容的API設計，這一點對于開源工具來說十分重要，讓用戶可以更少的遷移成本；第二個是擁抱社區，提供了很多很現代的功能，比如瀏覽器模式、源碼內聯測試；第三個基于vite的設計理念，使用現代的API和工具，讓開發者開箱即用ESM和typescript，無需任何其他配置，提供更好的開發者體驗。
我們應該關注vitest最新特性，及時升級vitest，使用最新特性和技術來保證我們代碼的穩定性。
