مقایسه Vitest در مقابل Jest 2026

Jest نزدیک به یک دهه است که تست جاوا اسکریپت را پشتیبانی می‌کند، اما تیم‌هایی که مقایسه‌های بزرگی بین Vitest و Jest 2026 انجام می‌دهند، همچنان به یک نتیجه می‌رسند: شکاف عملکرد واقعی است، داستان ESM مثل روز اول است، و مقایسه چارچوب تست جاوا اسکریپت به طور فزاینده‌ای Vitest را برای هر پروژه جدیدی ترجیح می‌دهد.

فهرست مطالب

چرا مکالمه‌ی شوخی و خنده به نقطه‌ی حساس رسید؟

امسال دو نیرو با هم برخورد کردند. اول اینکه، Jest 30 با بهبودهای تدریجی عرضه شد، اما معماری CJS-first و پرچم‌های آزمایشی ESM آن تا حد زیادی دست نخورده باقی ماندند. مستندات Jest هنوز یک صفحه اختصاصی برای ماژول‌های ECMAScript جدا از راهنمای اصلی «شروع به کار» دارند که تأکید می‌کند ESM همچنان یک شهروند درجه دو است که نیاز به پیکربندی صریح دارد. دوم اینکه، Vitest 3.x به سطحی از بلوغ و پذیرش اکوسیستم رسیده است که نادیده گرفتن آن را دشوار می‌کند. Nuxt، SvelteKit، Astro و جدیدترین ابزارهای Angular همگی با Vitest عرضه می‌شوند یا آن را به صورت پیش‌فرض توصیه می‌کنند.

این یک بحث داغ در مورد اینکه کدام فریم‌ورک «بهتر» است نیست. این یک راهنمای مهاجرت مبتنی بر داده‌ها است که از یک مهاجرت واقعی در محیط عملیاتی ساخته شده و شامل اعداد معیار، یک راهنمای گام به گام و ده نکته‌ای است که مستندات رسمی از آنها چشم‌پوشی می‌کنند.

اکوسیستم تست در سال ۲۰۲۶: چه چیزی تغییر کرد

جِست ۳۰: چه چیزهایی جدید است و چه چیزهایی هنوز از قلم افتاده است

Jest 30 بهبودهای خوبی را به همراه داشت: کار بر روی عملکرد jest-haste-map ، یک فرمت snapshot به‌روزرسانی‌شده، و تکرار مداوم پشتیبانی از ESM. اما ESM همچنان در پشت پرچم‌های آزمایشی و سطوح API جداگانه محصور مانده است. شبیه‌سازی یک ماژول ESM هنوز به jest.unstable_mockModule جفت‌شده با فراخوانی‌های پویای await import() به جای jest.mock() همگام‌سازی‌شده‌ی آشنا نیاز دارد. خط لوله تبدیل، که به طور پیش‌فرض حول Babel ساخته شده است (یا @swc/jest برای سرعت)، هنوز هر فایل را قبل از اجرا پردازش می‌کند. و moduleNameMapper ، تیم‌های escape hatching که برای مسیریابی به آن متکی هستند، با افزایش تعداد بسته‌هایی که ESM خالص ارائه می‌دهند، به طور فزاینده‌ای شکننده می‌شود.

Vitest 3.x: ESM بومی، اکوسیستم رو به رشد مبتنی بر Vite

Vitest 3.x به خط لوله تبدیل Vite متکی است، به این معنی که TypeScript، JSX و ESM بدون پیکربندی یک زنجیره تبدیل جداگانه کار می‌کنند. حالت مرورگر تثبیت شده است، پشتیبانی از فضای کاری، monorepos را به صورت بومی مدیریت می‌کند و snapshotهای درون خطی (inline snapshots) اصلاح شده‌اند. تفاوت مهم معماری: Vitest ESM را از طریق کدهای سازگاری شبیه‌سازی نمی‌کند. کد شما را از طریق خط لوله ماژول Vite در Node (یا در یک مرورگر واقعی از طریق حالت مرورگر) اجرا می‌کند، بنابراین فایل‌های import.meta ، await سطح بالا و .mjs به درستی کار می‌کنند. بدون پرچم (flag). بدون راه حل.

سیگنال‌های اکوسیستمی که اهمیت دارند

نظرسنجی وضعیت جاوااسکریپت در سال ۲۰۲۴ نشان داد که Vitest در امتیاز رضایت توسعه‌دهندگان از Jest پیشی گرفته است و روند دانلود هفتگی npm نشان می‌دهد که منحنی رشد Vitest شیب تندتری دارد در حالی که منحنی Jest شیب ثابتی دارد. وقتی چارچوب‌هایی که برنامه شما بر اساس آنها ساخته شده است، یک ابزار تست را توصیه می‌کنند، این سیگنال اهمیت پیدا می‌کند.

معیار رو در رو: ۵۰،۰۰۰ آزمایش در حال انجام

محیط و روش آزمایش

ما در مقایسه با مونوریپوی تولیدی خود آزمایش کردیم: ۱۲ بسته، تقریباً ۵۰۰۰۰ آزمایش شامل تست‌های کامپوننت React (Testing Library + jsdom)، تست‌های ادغام سرویس Node و تست‌های واحد محض. سخت‌افزار استانداردسازی شد: GitHub Actions large runners (۸ هسته‌ای، ۱۶ گیگابایت رم) برای اعداد CI، و یک MacBook Pro 2023 (M3 Pro، ۳۶ گیگابایت رم) برای اعداد توسعه محلی. هر اندازه‌گیری میانگین پنج اجرای متوالی است. ما --forceExit در Jest غیرفعال کردیم تا از خاموش شدن‌های بی‌نقص اطمینان حاصل شود. هر دو پیکربندی از jsdom به عنوان محیط آزمایش برای بسته‌های UI و از Node برای بسته‌های سرویس استفاده کردند.

Jest نسخه 30.x را با @swc/jest به عنوان مبدل اجرا کرد. Vitest نسخه 3.x را با پیکربندی پیش‌فرض Vite و بدون هیچ گونه تغییر اضافی در بهینه‌ساز اجرا کرد.

نتایج بنچمارک

ما انتظار داشتیم که بهبود شروع سرد (cold start) زیاد باشد. کاهش ۶۶ درصدی همچنان ما را غافلگیر کرد. تفاوت در حالت watch حتی چشمگیرتر بود. عصر جمعه یک تابع کاربردی واحد را تغییر دادم، فایل را ذخیره کردم و Vitest سه فایل آزمایشی تحت تأثیر را در ۳۸۰ میلی‌ثانیه دوباره اجرا کرد. چرخه watch معادل Jest 3.4 ثانیه طول کشید زیرا --onlyChanged در Jest به جای نمودار وابستگی ماژول، به اکتشافات git diff متکی است.

عصر جمعه یک تابع کاربردی را تغییر دادم، فایل را ذخیره کردم و Vitest سه فایل آزمایشی تحت تأثیر قرار گرفته را در مدت زمان ۳۸۰ میلی‌ثانیه دوباره اجرا کرد.

جایی که ویتست پیروزی‌های بزرگی به دست می‌آورد

شروع سرد و کشف فایل، بزرگترین بخش از شکاف عملکرد را تشکیل می‌دهند. jest-haste-map در Jest، کل پروژه را از قبل بررسی می‌کند تا نقشه ماژول خود را بسازد. تبدیل بر اساس تقاضا در Vite به این معنی است که Vitest فقط فایل‌هایی را که در طول اجرای تست وارد می‌شوند، پردازش می‌کند. برای حالت watch، Vitest نمودار واردات را ردیابی می‌کند (مشابه نمودار HMR در Vite در dev)، بنابراین تغییر یک فایل کاربردی فقط تست‌هایی را که به صورت گذرا آن را وارد می‌کنند، فعال می‌کند.

پشتیبانی بومی از ESM همچنین یک دسته کامل از سردردهای پیکربندی را از بین می‌برد. ما در Jest فقط برای مدیریت بسته‌های ESM، 14 ورودی moduleNameMapper داشتیم. در Vitest، همه آنها را حذف کردیم.

جایی که شوخی هنوز پابرجاست

سریالایزرهای اسنپ‌شات Jest برای درخت‌های کامپوننت پیچیده، به خصوص سریالایزرهای سفارشی که propهای فرار را حذف می‌کنند، بالغ‌تر باقی می‌مانند. پرچم --shard Jest ( jest --shard=1/3 ) برای تقسیم مجموعه‌های عظیم بین اجراکننده‌های CI مقاوم شده است. Vitest از sharding پشتیبانی می‌کند، اما ما پیاده‌سازی Jest را برای مجموعه‌های بالای 80000 تست کمی قابل پیش‌بینی‌تر یافتیم. پیاده‌سازی تایمر جعلی Jest همچنین موارد حاشیه‌ای را در کتابخانه زمان‌بندی cron ما با اطمینان بیشتری مدیریت کرد. ما مجبور شدیم دو تست وابسته به تایمر را پس از مهاجرت به vi.useFakeTimers() تنظیم کنیم.

پیکربندی پهلو به پهلو

export default { projects : [ '<rootDir>/packages/api' , '<rootDir>/packages/web' , '<rootDir>/packages/shared' , ] , transform : { '^.+\\.(ts|tsx)$' : [ '@swc/jest' ] , } , moduleNameMapper : { '^@shared/(.*)$' : '<rootDir>/packages/shared/src/$1' , } , testEnvironment : 'node' , coverageProvider : 'v8' , } ;

export default [ 'packages/api' , 'packages/web' , 'packages/shared' , ] ;

import { defineConfig } from 'vitest/config' ; import { resolve } from 'path' ;
export default defineConfig ( { resolve : { alias : { '@shared' : resolve ( __dirname , 'packages/shared/src' ) , } , } , test : { environment : 'node' , coverage : { provider : 'v8' } , } , } ) ;

به عدم وجود کلید transform در Vitest توجه کنید. Vite به صورت بومی TypeScript و JSX را از طریق esbuild مدیریت می‌کند.

کتاب راهنمای مهاجرت: گام به گام

مرحله ۱: پیچیدگی پیکربندی Jest خود را بررسی کنید

قبل از نصب هر چیزی، پیکربندی Jest خود را بررسی کنید. jest.config.ts خود را باز کنید و هر فیلد غیر پیش‌فرض را حاشیه‌نویسی کنید:

export default {  
testEnvironment : 'jsdom' ,
  
setupFilesAfterEnv : [ './test/setup.ts' ] ,
  
moduleNameMapper : { '^@/(.*)$' : '<rootDir>/src/$1' , '\\.css$' : 'identity-obj-proxy' , } ,
  
transform : { '^.+\\.tsx?$' : [ '@swc/jest' ] , } ,
  
coverageThreshold : { global : { branches : 80 , lines : 90 } , } , } ;

فایل‌های تست خود را برای APIهای مختص Jest، مانند jest.fn() ، jest.spyOn() ، jest.mock() ، jest.useFakeTimers() و jest.requireActual() با دستور Grep بررسی کنید. تعداد آنها را بشمارید. در کدبیس ما، ۱۸۴۷ فراخوانی jest.mock() و بیش از ۳۲۰۰ ارجاع به jest.fn() پیدا کردیم. این عدد تعیین می‌کند که آیا یک codemod چند روز یا چند هفته در زمان شما صرفه‌جویی می‌کند.

مرحله ۲: نصب Vitest و اجرای Codemods

 npm install -D vitest @vitest/coverage-v8 @vitest/ui



npx jest-to-vitest --write

کد ماژول انجمن jest-to-vitest تغییر نام‌های مکانیکی را مدیریت می‌کند: jest.fn() تبدیل به vi.fn() می‌شود، jest.spyOn() تبدیل به vi.spyOn() می‌شود، jest.mock() تبدیل به vi.mock() می‌شود. در اینجا یک نمونه قبل و بعد از آن را مشاهده می‌کنید:

import { render , screen } from '@testing-library/react' ; import { UserCard } from './UserCard' ; import * as api from '../api/users' ;
jest . mock ( '../api/users' ) ;
describe ( 'UserCard' , ( ) => { it ( 'displays the user name' , async ( ) => { jest . spyOn ( api , 'fetchUser' ) . mockResolvedValue ( { name : 'Alice' } ) ; render ( < UserCard id = "1" / > ) ; expect ( await screen . findByText ( 'Alice' ) ) . toBeInTheDocument ( ) ; } ) ; } ) ;

import { render , screen } from '@testing-library/react' ; import { UserCard } from './UserCard' ; import * as api from '../api/users' ;
vi . mock ( '../api/users' ) ;
describe ( 'UserCard' , ( ) => { it ( 'displays the user name' , async ( ) => { vi . spyOn ( api , 'fetchUser' ) . mockResolvedValue ( { name : 'Alice' } ) ; render ( < UserCard id = "1" / > ) ; expect ( await screen . findByText ( 'Alice' ) ) . toBeInTheDocument ( ) ; } ) ; } ) ;

codemod این تغییر نام‌ها را به طور قابل اعتمادی مدیریت می‌کند. مواردی که از قلم افتاده‌اند: ارجاعات متغیر تابع factory درون vi.mock() ، جایگزینی‌های سفارشی moduleNameMapper ، مسیرهای ایمپورت jest-dom و تغییر ساختار callback تابع done() به async/await. این موارد نیاز به مداخله دستی دارند.

مرحله ۳: اختلاف ارتفاع ساختگی را مدیریت کنید (بزرگترین مشکل)

این رایج‌ترین شکست مهاجرت است. هر دو تابع hoist در Jest و Vitest mock() را به بالای فایل فراخوانی می‌کنند، اما hoist کردن در Vitest قوانین دامنه‌بندی متفاوتی برای متغیرهایی که درون توابع factory ارجاع داده می‌شوند، دارد.

const mockFetch = vi . fn ( ) ;
vi . mock ( '../api/users' , ( ) => ( { fetchUser : mockFetch , } ) ) ;

راه حل vi.hoisted() است که به صراحت مقادیر موجود در محدوده hoisted را ایجاد می‌کند:

const { mockFetch } = vi . hoisted ( ( ) => ( { mockFetch : vi . fn ( ) , } ) ) ;
vi . mock ( '../api/users' , ( ) => ( { fetchUser : mockFetch , } ) ) ;

متوجه شدم که تقریباً ۴۰٪ از فراخوانی‌های vi.mock() ما با توابع factory به این روش نیاز دارند. وقتی تست‌های packages/auth را بعد از codemod اجرا کردم، ۲۳ تا از ۵۸ factory ساختگی، خطاهای ارجاع undefined تولید می‌کردند تا اینکه آنها را با vi.hoisted() بازسازی کردم.

متوجه شدم که تقریباً ۴۰٪ از فراخوانی‌های vi.mock() ما با توابع کارخانه‌ای به این روش نیاز دارند.

مرحله ۴: انتقال فایل پیکربندی

نگاشت‌های کلیدی از پیکربندی Jest به پیکربندی Vitest:

testEnvironment → test.environment ( 'jsdom' , 'happy-dom' , 'node' )

setupFilesAfterEnv → test.setupFiles

moduleNameMapper → resolve.alias در پیکربندی Vite

coverageThreshold → test.coverage.thresholds

transform → معمولاً به‌طور کامل حذف می‌شود؛ Vite آن را مدیریت می‌کند

globals: true در پیکربندی تست Vitest، describe / it / expect بدون import فعال می‌کند (شبیه به globals در Jest)، اگرچه importهای صریح از vitest برای ایمنی نوع توصیه می‌شود.

اگر globals: true را فعال کرده‌اید، برای جلوگیری از خطاهای TypeScript، "types": ["vitest/globals"] را به tsconfig.json خود اضافه کنید.

مرحله 5: به‌روزرسانی خط لوله CI

- name: Test run: npx jest --ci --coverage --maxWorkers = 4

- name: Test run: npx vitest run --coverage --reporter = verbose

Vitest به طور خودکار از نخ‌های کارگر منطبق با هسته‌های موجود استفاده می‌کند. برای پوشش، v8 ارائه‌دهنده پیش‌فرض است و به طور قابل توجهی سریع‌تر از Istanbul است. فقط در صورتی از Istanbul ( coverage.provider: 'istanbul' ) استفاده کنید که به دقت پوشش شاخه برای عبارات شرطی پیچیده نیاز دارید، جایی که ابزار دقیق V8 گاهی اوقات گزارش‌های نادرستی می‌دهد. این رویکرد همچنین زمانی که افزونه‌های Node بومی در مسیر تست خود دارید که با ابزار دقیق پوشش V8 سازگار نیستند، با شکست مواجه می‌شود، که در این صورت Istanbul انتخاب امن‌تری است.

ده اشتباه مهاجرتی که هیچ‌کس در موردشان به شما هشدار نمی‌دهد

۱. vi.mock() بالا بردن محدوده. در بالا توضیح داده شد. vi.hoisted() استفاده کنید. این مورد اکثر مجموعه‌های تست قرمز پس از مهاجرت را تشکیل می‌دهد.

۲. تفاوت‌های سینتکس moduleNameMapper با عبارات منظم. Jest از توکن‌های <rootDir> و regex escaping خاص استفاده می‌کند. Vitest از resolve.alias ویت استفاده می‌کند که یا مسیرهای رشته‌ای یا عبارات منظم را می‌پذیرد. کپی کردن و چسباندن الگوهای عبارات منظم Jest در resolve.alias بی‌صدا باعث خرابی می‌شود.

۳. پیش‌فرض‌های API تایمرهای جعلی. پیش‌فرض‌های vi.useFakeTimers() با jest.useFakeTimers() متفاوت است. Vitest در داخل @sinonjs/fake-timers و به طور پیش‌فرض از fakes Date استفاده می‌کند؛ تایمرهای جعلی مدرن Jest (که بر اساس @sinonjs/fake-timers ساخته شده‌اند) نیز همین کار را می‌کنند، اما رفتار advanceTimersByTime با setImmediate می‌تواند متفاوت باشد. کد سنگین تایمر را به صورت دستی آزمایش کنید.

۴. محل فایل اسنپ‌شات. Jest اسنپ‌شات‌ها را در __snapshots__/ در مجاورت فایل‌های تست ذخیره می‌کند. Vitest نیز به طور پیش‌فرض همین کار را انجام می‌دهد، اما پسوند و فرمت فایل کمی متفاوت است. برای بازسازی خطوط پایه پس از مهاجرت، vitest run --update را اجرا کنید.

۵. الگوهای فراخوانی done() . هیچ‌کدام از چارچوب‌ها رسماً done() منسوخ نکرده‌اند، اما Vitest وقتی با توابع async ترکیب می‌شود، آن را با ظرافت کمتری مدیریت می‌کند. برای جلوگیری از خطاهای بی‌صدای timeout، آن را به async/await تغییر دهید.

۶. تداخل‌های نوع expect سراسری. اگر پروژه شما Chai را مستقیماً وارد کند (Vitest به صورت داخلی expect مبتنی بر Chai استفاده می‌کند)، TypeScript می‌تواند اعلان‌های نوع تکراری را نمایش دهد. انواع Chai را از tsconfig خود حذف کنید یا به طور صریح از expect نوع Vitest استفاده کنید.

۷. تطبیق‌دهنده‌های jest-dom . در فایل تنظیمات خود، @testing-library/jest-dom با @testing-library/jest-dom/vitest جایگزین کنید. تغییر مسیر ایمپورت یک خط است، اما اگر آن را فراموش کنید، کل مجموعه دستورات DOM مسدود می‌شود. توجه: این نقطه ورود اختصاصی Vitest در @testing-library/jest-dom نسخه ۶.۶.۰ قرار دارد، بنابراین مطمئن شوید که حداقل از آن نسخه استفاده می‌کنید.

۸. تابع import() پویا در ماژول‌های Mocked. الگوی jest.unstable_mockModule به همراه الگوی dynamic import() در Jest، به صورت ۱:۱ به vi.mock() نگاشت نمی‌شود. Vitest به صورت بومی و بدون API ناپایدار، ESM mocking را مدیریت می‌کند، اما توابع factory در نقطه چرخه عمر متفاوتی اجرا می‌شوند.

۹. --forceExit در Vitest وجود ندارد. اگر مجموعه Jest شما نیاز به --forceExit برای خاتمه دادن داشت، شما هندل‌های باز (اتصالات پایگاه داده، جریان‌های تخلیه نشده) دارید. Vitest این موارد را به عنوان هشدارهای تست معلق نشان می‌دهد. به جای پوشاندن علت اصلی، آن را برطرف کنید.

۱۰. پیکربندی فضای کاری Monorepo با پروژه‌های Jest یک به یک نیست. آرایه projects در Jest در فایل پیکربندی مستقیماً به vitest.workspace.ts تبدیل نمی‌شود. فضاهای کاری Vitest الگوهای glob یا مسیرهای دایرکتوری را تعریف می‌کنند و هر فضای کاری می‌تواند پیکربندی پایه را لغو کند. برای یک پکیج بیش از ۱۰ تایی monorepo، ۳۰ دقیقه تنظیم دستی لازم است.

چک لیست مهاجرت (آماده کپی و پیست)

 - [ ] Audit `jest.config.*` for custom transforms, moduleNameMapper, setupFiles - [ ] Install `vitest`, `@vitest/coverage-v8`, `@vitest/ui` - [ ] Run `jest-to-vitest` codemod across all test files - [ ] Replace `jest.mock()` factory variable references with `vi.hoisted()` - [ ] Migrate `jest.config.*` to `vitest.config.*` (or embed in `vite.config.*`) - [ ] Switch `@testing-library/jest-dom` to `@testing-library/jest-dom/vitest` - [ ] Update `setupFiles` paths and verify setup file content works under Vitest - [ ] Add `"types": ["vitest/globals"]` to tsconfig (if using globals mode) - [ ] Ensure Vite plugins (React, Svelte, Vue) are loaded in test config - [ ] Replace `done()` callbacks with async/await patterns - [ ] Update CI workflow: `npx jest --ci` → `npx vitest run` - [ ] Run full suite, review snapshot diffs, regenerate baselines - [ ] Compare coverage output, configure `test.coverage.thresholds` - [ ] Remove Jest dependencies (`jest`, `@swc/jest`, `ts-jest`, etc.) from package.json - [ ] Update `CONTRIBUTING.md` and developer onboarding docs

چه زمانی نباید مهاجرت کنید (هنوز)

همه تیم‌ها نباید همین الان مهاجرت کنند. اگر سرمایه‌گذاری زیادی روی پرچم --shard در Jest برای مجموعه‌هایی با بیش از ۱۰۰۰۰۰ تست انجام داده‌اید و تنظیم CI شما دقیقاً به همان رفتار شاردینگ بستگی دارد، شاردینگ Vitest کار می‌کند اما در آن مقیاس مسافت کمتری را طی می‌کند. اگر کدبیس شما به طور گسترده به الگوهای factory jest.mock() با closureهای متغیر پیچیده متکی است و تیم شما فاقد پهنای باند برای بازسازی دستی صدها factory ساختگی است، هزینه مهاجرت واقعی است. پروژه‌های سازمانی قدیمی که به محیط‌های صرفاً مبتنی بر CommonJS قفل شده‌اند و Vite در زنجیره ابزار آنها وجود ندارد، وجود دارند و اجبار Vite به آن پشته، مشکلات بیشتری را نسبت به حل آنها ایجاد می‌کند. و اگر زمان‌های CI شما از قبل قابل قبول هستند و توسعه‌دهندگان از سرعت حالت watch شکایتی ندارند، مهاجرت به خودی خود هزینه‌ای را به همراه دارد که ممکن است به خودی خود جبران نشود.

آیا باید در سال ۲۰۲۶ مهاجرت کنید؟

برای پروژه‌های جدید، Vitest انتخاب پیش‌فرض است. پیکربندی ساده‌تر است، ESM بدون تشریفات کار می‌کند و مزیت عملکرد با رشد مجموعه تست، افزایش می‌یابد.

آیا یک پروژه Jest با کمتر از ۵۰۰۰ تست و پیکربندی سرراست دارید؟ من دیده‌ام که مهاجرت آن تقریباً یک روز برای یک توسعه‌دهنده طول می‌کشد، از جمله اجرای codemod، رفع اشکالات دستی و به‌روزرسانی‌های CI. بهبود حالت watch به تنهایی این زمان را توجیه می‌کند.

برای مونوریپوهای بزرگ Jest با بیش از ۱۰،۰۰۰ تست، یک مهاجرت مرحله‌ای، هر بار یک بسته، برنامه‌ریزی کنید. مهاجرت ۵۰،۰۰۰ تستی ما دو هفته کار متمرکز را برای سه مهندس به طول انجامید و خط لوله CI از ۱۴ دقیقه به کمتر از ۵ دقیقه رسید. این کار تقریباً ۴۵ دقیقه از زمان انتظار توسعه‌دهندگان را برای هر درخواست pull در یک تیم ۳۰ نفره از مهندسان آزاد کرد.

مهاجرت ۵۰،۰۰۰ تستی ما دو هفته کار متمرکز را صرف سه مهندس کرد و زمان خط لوله CI از ۱۴ دقیقه به کمتر از ۵ دقیقه رسید.

Jest نمرده است. همچنان یک چارچوب تست توانمند و مستندسازی‌شده با یک اکوسیستم عظیم است. اما Vitest جایی است که شتاب تست جاوااسکریپت در آن جریان دارد و با هر انتشار، شکاف بیشتر می‌شود. هر ماه که منتظر می‌مانید، الگوهای مختص Jest بیشتری در پایگاه کد شما انباشته می‌شوند و مهاجرت نهایی را دشوارتر می‌کنند. معیارها می‌گویند حرکت کنید. تجربه توسعه‌دهنده می‌گوید حرکت کنید. اکوسیستم می‌گوید حرکت کنید. تنها سوال این است که چه زمانی، و برای اکثر تیم‌ها، پاسخ اکنون است.

تست مسدودسازی تبلیغات