Vitest 5 vs Jest Karşılaştırması

Vite'ın kendi hızıyla native ESM/TS test runner'ı

VS
Jest

13 yıllık, olgun ve React Native'in varsayılanı

17 dk okumaAraçlar

Hızlı Karar

Vite veya Nuxt tabanlı yeni projede varsayılanın Vitest olmalı: aynı `vite.config.js`'i paylaşırsın. Next.js'te config ayrı kalır (derleyicisi Vite değil), ama native ESM/TypeScript'i ek transform paketi kurmadan alırsın. Ama çalışan büyük bir Jest suite'in varsa, özellikle RN/Metro'ya bağımlıysan göçün maliyeti kazancı aşabilir. Üçüncü yolu seç: yeni testleri Vitest'te yaz, mevcut suite'i Jest'te bırak — ikisi aynı monorepo'da yaşayabilir.

Vitest 5Jest
Tam sonucu oku

Puan Karşılaştırması

Grafik yükleniyor...

Detaylı Puanlama

Detaylı Puanlama: Vitest 5 ve Jest — kategori bazında 10 üzerinden puanlar
KategoriVitest 5Jest
Performans
9/10
7/10
Öğrenme Kolaylığı
7/10
7/10
Ekosistem
6/10
9/10
Topluluk
6/10
9/10
İş Pazarı
6/10
8/10
Gelecek
9/10
6/10

Artıları & Eksileri

Vitest 5

Artıları

  • Aynı vite.config.js'i uygulamayla paylaşır, ayrı bir transform katmanı gerekmez
  • Native ESM paketi ("type": "module"), deneysel bayrak gerekmez
  • Vitest 5'te ölçülen senaryolarda senaryoya göre %8-%53 hız kazanımı (bazı yapılandırmalarda fark ±%3)
  • First-party Browser Mode + Vitest 5'te yeni Trace View
  • Jest'e benzer mocking API'si (vi.fn/vi.mock) + yeni vi.when koşullu mock
  • Nested project inheritance ile daha granüler monorepo desteği
  • 790+ katkıcı ile hızla büyüyen, Vite ekibinin desteklediği bir proje

Eksileri

  • Node 22.12+ / 24.x / 26+ zorunlu — ara sürümler (23.x, 25.x) desteklenmiyor
  • Yarn'da vite artık peer dependency, elle kurulmazsa paket çözülemiyor
  • React Native/Metro için first-party desteği yok
  • GitHub yıldızı (17.151) Jest'in yaklaşık üçte biri — ekosistem daha genç
  • Vitest 5'teki davranış değişiklikleri (clearMocks, top-level vi.mock) sessiz kırılmalara yol açabilir

En Uygun

Vite, Next.js veya Nuxt tabanlı yeni web projeleriComponent/browser-level test yazan ekiplerVite paylaşımlı config isteyen monorepo'larHızlı watch-mode / CI süresi kritik olan projelerNative ESM + TypeScript ağırlıklı kod tabanları

Jest

Artıları

  • Tek --coverage bayrağıyla ek kurulum gerektirmeyen coverage
  • Geniş Node sürümü desteği (^18.14'ten itibaren)
  • React Native'in varsayılan şablonunda gelen test çerçevesi; Expo tarafında resmi jest-expo preset'i
  • 45.467 GitHub yıldızı ile Vitest'in ~2,65 katı büyüklükte ekosistem
  • --projects bayrağıyla çoklu-paket monorepo desteği
  • Testleri kendi process'lerinde paralelleştiren olgun mimari
  • 30.5.2'de Node'un yerleşik TS-strip desteğiyle transform yükünü azaltmaya başladı

Eksileri

  • ESM desteği hâlâ resmi olarak "deneysel" — ek bayrak ve elle transform ayarı gerekiyor
  • TypeScript/modern JS için ayrı transform paketleri (babel-jest/ts-jest) kurulmalı
  • Vite config'ini paylaşmıyor — Vite tabanlı projede iki ayrı yapılandırma
  • First-party browser mode veya component testing özelliği yok

En Uygun

React Native / Expo uygulamalarıBüyük, mevcut ve çalışan Jest suite'i olan projelerNode sürümü eski sabitlenmiş CI ortamlarıÖzel Babel/transformer zincirine bağımlı kod tabanlarıOpenJS Foundation şemsiyesinde kurumsal sürdürülebilirlik önemseyen ekipler

Kod Karşılaştırması

Vitest 5
// Vitest 5 - Sepet toplamı hesaplayan fonksiyonun testi
// vitest.config.ts, vite.config.ts'i paylaşır; ek transform gerekmez
import { describe, it, expect, vi } from 'vitest'
import { calculateCartTotal } from './cart'
import { fetchDiscount } from './discount-api'

vi.mock('./discount-api')

describe('calculateCartTotal', () => {
  // Vitest 5: clearMocks varsayılan true, ek temizleme çağrısı gerekmez
  it('indirim kodu olmadan ara toplami dogru hesaplar', () => {
    const items = [
      { price: 129.9, qty: 2 },
      { price: 49.5, qty: 1 },
    ]
    expect(calculateCartTotal(items)).toBeCloseTo(309.3, 2)
  })

  it('gecerli indirim kodunda vi.when ile kosullu mock kullanir', async () => {
    // Vitest 5 yeni API: argümana göre farklı mock davranışı
    vi.when(fetchDiscount).calledWith('SEPET10').thenResolve({ percent: 10 })
    vi.when(fetchDiscount).calledWith('GECERSIZ').thenReject(new Error('invalid code'))

    const items = [{ price: 100, qty: 1 }]
    const total = await calculateCartTotal(items, 'SEPET10')

    expect(total).toBeCloseTo(90, 2)
    expect(fetchDiscount).toHaveBeenCalledWith('SEPET10')
  })

  it('gecersiz kod hata firlatir', async () => {
    vi.when(fetchDiscount).calledWith('GECERSIZ').thenReject(new Error('invalid code'))
    const items = [{ price: 100, qty: 1 }]

    await expect(calculateCartTotal(items, 'GECERSIZ')).rejects.toThrow('invalid code')
  })
})

// Monorepo: vitest -p web --coverage (yalnız 'web' projesi + kapsam raporu)
Jest
// Jest 30 - Sepet toplamı hesaplayan fonksiyonun testi
// babel.config.js veya ts-jest transform zinciri ayrıca kurulmuş olmalı
const { calculateCartTotal } = require('./cart')
const { fetchDiscount } = require('./discount-api')

jest.mock('./discount-api')

describe('calculateCartTotal', () => {
  afterEach(() => {
    jest.clearAllMocks() // Jest'te varsayılan değildir, elle çağrılır
  })

  it('indirim kodu olmadan ara toplami dogru hesaplar', () => {
    const items = [
      { price: 129.9, qty: 2 },
      { price: 49.5, qty: 1 },
    ]
    expect(calculateCartTotal(items)).toBeCloseTo(309.3, 2)
  })

  it('gecerli indirim kodunda mockResolvedValue kullanir', async () => {
    fetchDiscount.mockImplementation((code) => {
      if (code === 'SEPET10') return Promise.resolve({ percent: 10 })
      return Promise.reject(new Error('invalid code'))
    })

    const items = [{ price: 100, qty: 1 }]
    const total = await calculateCartTotal(items, 'SEPET10')

    expect(total).toBeCloseTo(90, 2)
    expect(fetchDiscount).toHaveBeenCalledWith('SEPET10')
  })

  it('gecersiz kod hata firlatir', async () => {
    fetchDiscount.mockRejectedValue(new Error('invalid code'))
    const items = [{ price: 100, qty: 1 }]

    await expect(calculateCartTotal(items, 'GECERSIZ')).rejects.toThrow('invalid code')
  })
})

// jest --projects packages/web --coverage ile monorepo'da yalnızca 'web' paketini çalıştır

Sonuç

Vite veya Nuxt tabanlı yeni projede varsayılanın Vitest olmalı: aynı `vite.config.js`'i paylaşırsın. Next.js'te config ayrı kalır (derleyicisi Vite değil), ama native ESM/TypeScript'i ek transform paketi kurmadan alırsın. Ama çalışan büyük bir Jest suite'in varsa, özellikle RN/Metro'ya bağımlıysan göçün maliyeti kazancı aşabilir. Üçüncü yolu seç: yeni testleri Vitest'te yaz, mevcut suite'i Jest'te bırak — ikisi aynı monorepo'da yaşayabilir.

Ücretsiz Danışmanlık Al
SSS

Sıkça Sorulan Sorular

Hayır, birebir yerini almıyor. İkisi de Eylül 2026'da aktif geliştiriliyor: Vitest 5.0 (3 Eylül 2026) ve Jest 30.5.2 (18 Eylül 2026). Vite ve Nuxt tabanlı projelerde Vitest uygulamanın kendi transform hattını yeniden kullandığı için kurulum yükü daha düşük; Jest özellikle React Native/Metro ve mevcut büyük kod tabanlarında sürmeye devam ediyor.

Giriş

Vite tabanlı bir projede yeni bir test runner'a karar vermen gerekiyorsa, 2026 Eylül'ü tam da bunu sormanın zamanı: Vitest 5.0, 3 Eylül 2026'da yayınlandı ve performans odaklı, Node 22 + Vite 6.4 gerektiren bir majör sürüm. Aynı anda Jest de durmuyor — 18 Eylül 2026'da 30.5.2'ye güncellendi ve TypeScript transform yükünü hafifletmeye çalışıyor. Bu, "biri ölüyor, biri kazanıyor" hikâyesi değil. Bu sayfada seni ilgilendiren soruyu netleştireceğiz: Vite/Next/Nuxt tabanlı yeni bir projede hangisini seçmelisin, ve mevcut büyük bir Jest suite'in ya da React Native/Metro bağımlılığın varsa göç mantıklı mı? Kurulum yükünden ESM/TS desteğine, browser mode'dan mocking API'sine, coverage motorundan monorepo desenine kadar her kritere resmi kaynaklarla (vitest.dev, jestjs.io, GitHub Releases) bakacağız — uydurma benchmark yok, yalnız doğrulanabilir rakamlar.

Karşılaştırma Matrisi

Karşılaştırma Matrisi: Vitest 5 / Jest
ÖzellikVitest 5Jest
Güncel sürüm (2026-09-23)5.0.130.5.2
Node.js gereksinimi22.12+ / 24.x / 26+^18.14 / ^20 / ^22 / ≥24 (Öne çıkan)
Native ESMtype: module (native) (Öne çıkan)Experimental (--experimental-vm-modules)
Vite config paylaşımıAynı vite.config.js (Öne çıkan)Ayrı config gerekir
Browser mode (first-party)Var (Playwright/WebdriverIO/preview) (Öne çıkan)Yok
Coverage kurulumuv8/istanbul, ek ayar gerekebilirTek --coverage bayrağı (Öne çıkan)
Monorepo modelitest.projects, nested inheritance (Öne çıkan)--projects bayrağı
React Native/Metro desteğiFirst-party yokVarsayılan preset (jest-expo) (Öne çıkan)
GitHub yıldızı17.15145.467 (Öne çıkan)
Repo yaşı2021 (created_at)2013 (org created_at) (Öne çıkan)
LisansMITMIT
Watch-mode varsayılanıDeğişen dosyaları izler-o modu (değişenle ilgili testler)
Mocking API stilivi.fn/vi.mock (Jest'e benzer) + vi.whenjest.fn/jest.mock

Derinlemesine İnceleme

Vitest 5

Genel Bakış

Vitest, Vite ekosisteminin test runner'ı olarak 2021'de (repo 2021-12-03'te açıldı) doğdu ve Vite'ın kendi transform/plugin altyapısını test katmanına taşıma fikri üzerine kuruldu. 3 Eylül 2026'da yayınlanan Vitest 5.0, performans odaklı bir majör sürüm: Node ≥22.12.0 ve Vite ≥6.4.0 zorunlu kılıyor, expect ve @vitest/runner paketlerini inline ediyor, nested proje config devralımını basitleştiriyor, Browser Mode'a yeni bir Trace View ekliyor ve v8/istanbul coverage motorlarını yeniliyor. MIT lisanslı, 790'dan fazla katkıcıya sahip ve OpenCollective bağışlarıyla finanse ediliyor. GitHub'da 17.151 yıldıza ulaştı — Jest'e göre daha genç ama Vite'ın büyümesiyle birlikte hızla yükselen bir ekosistem.

Ekosistem

Paket yöneticisi
npm / pnpm / Bun (Yarn'da peer dep elle kurulmalı)
Geliştirme ortamı
VS Code (Vitest extension)WebStorm
Popüler kütüphaneler
@vitest/coverage-v8@vitest/coverage-istanbul@vitest/ui@vitest/browserhappy-dom
GitHub yıldızı
17,151

Jest

Genel Bakış

Jest, GitHub'daki jestjs/jest deposu 10 Aralık 2013'te açılmış, MIT lisanslı bir JavaScript test çerçevesi. Meta (Facebook) bünyesinde doğdu; 11 Mayıs 2022'de yayımlanan resmi duyuruya göre proje sahipliği Meta'dan OpenJS Foundation üzerinden Jest Core ekibine devredildi — yani bugün bir vakıf şemsiyesi altında yürütülüyor. Node.js ekosisteminin en yerleşik test runner'larından biri haline geldi ve React Native'in varsayılan şablonunda hazır geliyor. 18 Eylül 2026'da yayınlanan 30.5.2 sürümü, @jest/transform'un artık transformer tanımlı değilse .ts/.mts/.cts dosyalarını Node'un yerleşik TypeScript-strip özelliğiyle işleyebilmesi gibi transform yükünü azaltan iyileştirmeler getirdi. GitHub'da 45.467 yıldızla, test runner kategorisinde hâlâ en büyük ekosisteme sahip araçlardan biri.

Ekosistem

Paket yöneticisi
npm / pnpm / Yarn
Geliştirme ortamı
VS Code (Jest extension)WebStorm
Popüler kütüphaneler
babel-jestts-jestjest-expo@testing-library/jest-domjest-environment-jsdom
GitHub yıldızı
45,467

Teknik Analiz

Kurulum ve yapılandırma yükü

Jest'i TypeScript veya modern ESM ile çalıştırmaya karar verdiğinde tek bir npm install jest yetmiyor: babel-jest + @babel/preset-env (ya da ts-jest) kurmalı ve ayrı bir babel.config.js yazmalısın — bu, jestjs.io'nun kendi kurulum dokümantasyonunda açıkça belirtiliyor. Vitest tarafında bu ek transform katmanı yok, çünkü Vitest zaten Vite'ın kendi transform pipeline'ını kullanıyor. Vitest 5'te dikkat etmen gereken bir değişiklik var: vite artık Vitest'in doğrudan bağımlılığı değil, peer dependency. npm, pnpm veya Bun kullanıyorsan sorun yok, otomatik kurulur; ama Yarn kullanıyorsan yükseltme sonrası vite'ı elle eklemezsen paket çözülemez — resmi migration guide bunu net bir uyarı olarak veriyor. Node sürüm gereksinimleri de farklı ve burada ayrıntıya dikkat etmelisin: Vitest'in npm engines alanı ^22.12.0 || ^24.0.0 || >=26.0.0 diyor — yani yalnız "22.12 ve üstü" değil, 23.x ve 25.x gibi ara sürümler de dışarıda. Jest ise ^18.14, ^20, ^22 veya ≥24 ile daha geniş bir aralığı destekliyor. Eski ya da tek sayılı bir Node sürümüne sabitlenmiş CI'ın varsa bu tek başına belirleyici olabilir.

Vite config paylaşımı ve watch-mode hızı

Vitest'in temel değer önerisi tek cümleyle özetlenir: uygulamanla aynı vite.config.js'i ve aynı transform boru hattını kullanan bir test runner. Geliştirme sunucusundaki alias'lar, plugin'ler ve ortam değişkenleri testte de birebir aynı davranır. Jest'in kendi resolve/transform katmanı var; Vite tabanlı bir projede iki ayrı yapılandırmayı senkron tutman gerekir. Hız tarafında iki ekip de kendi rakamını yayımlıyor. Vitest 5 blogu vitest-dev/benchmarks deposuyla (Apple M4, Node 24, 3 koşu medyanı) 4.1→5.0 farkını veriyor: enterprise-monolith (1.280 modül, forks-isolated) 7,24 sn→5,83 sn (%19), deps-heavy vmThreads 1,59 sn→0,74 sn (%53), long-haul 5,43 sn→4,06 sn (%25). Ama aynı tabloda micro-utils ve cpu-bound hücrelerinde kazanım %8'de kalıyor ve blog açıkça "ortam kurulumunun baskın olduğu hücreler ±%3 bandında kalır" diyor. Jest 30 duyurusu da kendi 29→30 farkını veriyor: büyük bir TypeScript uygulamasında %37 daha hızlı koşu ve %77 daha düşük bellek; server testleri ~1.350 sn / 7,8 GB'den ~850 sn / 1,8 GB'ye indi. İkisi aynı düzlemde değil: her ekip kendi önceki sürümüyle karşılaştırıyor, aralarında doğrudan bir A-B ölçümü yok.

ESM + TypeScript native desteği

Burada iki araç arasındaki en keskin fark ortaya çıkıyor. Jest'in kendi resmi dokümantasyonu ESM desteğini hâlâ "deneysel" (experimental) olarak nitelendiriyor: "implementasyon hatalar içerebilir ve bazı özellikler eksik olabilir" diyor ve aktivasyonu için Node'u --experimental-vm-modules bayrağıyla çalıştırmanı, ayrıca transform yapılandırmanı (transform: {} ya da ESM üretecek bir transformer) elle ayarlamanı istiyor. Vitest ise package.json'ında "type": "module" ile doğrudan native ESM paketi olarak dağıtılıyor — sende ek bir deneysel bayrak veya elle transform ayarı gerektirmiyor. TypeScript tarafında da aynı fark geçerli: Vitest, Vite'ın esbuild tabanlı transformunu kullandığı için .ts dosyaların ek kurulum olmadan çalışır. Jest 30.5.2'nin kendi changelog'u (18 Eylül 2026) bu boşluğu kapatmaya yönelik somut bir adım içeriyor: @jest/transform artık, hiçbir transformer tanımlı değilse, .ts/.mts/.cts dosyalarını Node'un yerleşik TypeScript-strip özelliğiyle işleyebiliyor. Bu, "Jest'i sürdürmenin gerekçesi daralıyor" görüşüne karşı hafif ama gerçek bir karşı hamle — Jest ekibi de ESM/TS transform yükünü azaltmaya çalışıyor, sıfırlanmış değil.

Browser mode, component testing ve mocking

Vitest'in resmi bir Browser Mode'u var: npx vitest init browser ile kurup preview, playwright veya webdriverio sağlayıcılarından birini seçerek testlerini gerçek bir tarayıcıda çalıştırabiliyorsun. Vitest 5 bu moda yeni bir "Trace View" ekledi — her etkileşimi, assertion'ı ve page.mark çağrısını DOM snapshot'ı olarak kaydeden, adım adım geri oynatılabilen bir görünüm. Chromium'da react-spa senaryosunda ölçülen kazanım 2,40 sn'den 2,01 sn'ye (yaklaşık %16). Jest'in resmi dokümantasyonunda eşdeğer, first-party bir browser-mode veya component-testing özelliği bulunmuyor; Jest projeleri bu ihtiyaç için ayrı araçlara (Cypress CT, Playwright CT) yöneliyor. Mocking tarafında Vitest'in API'si bilinçli olarak Jest'e benziyor (vi.fn/vi.mockjest.fn/jest.mock). Vitest 5 ayrıca yeni bir koşullu mock API'si ekledi: vi.when(fn).calledWith(1).thenResolve(...) — argümana göre farklı davranış tanımlama, derin eşitlik ve asymmetric matcher desteğiyle. Dikkat etmen gereken davranış değişikliği şu: Vitest 5'te clearMocks artık varsayılan olarak true — her testten önce vi.clearAllMocks() otomatik çağrılıyor; beforeAll seviyesinde mock kuran projeler en çok etkilenen grup.

Coverage motoru ve monorepo desteği

Coverage tarafında Jest'in avantajı basitlik: tek bir --coverage bayrağıyla, ek kurulum yapmadan çalışıyor. Vitest'te hem v8 hem istanbul sağlayıcısını seçebiliyorsun; Vitest 5'te v8 sağlayıcısı raporları sınırlı bellek kullanımıyla birleştirecek şekilde iyileştirildi, istanbul sağlayıcısı da artık aktif bakımı yapılan @vitest/istanbuljs paketlerine taşındı. Büyük projelerde bu, raporlama hızını ve kararlılığını doğrudan etkiliyor. Monorepo/çoklu-proje desteğinde Vitest 5 yapısal bir değişiklik getirdi: iç içe (nested) projeler artık varsayılan olarak root config'i devralıyor — önceden zorunlu olan extends: true kaldırıldı — ve test.projects içinde referans verilen bir config dosyası artık kendi projects tanımını root'u tekrar etmeden yapabiliyor. Filtreleme için --project bayrağına -p kısayolu eklendi (vitest -p app). Jest'in de --projects bayrağıyla birden fazla config'i tek komutla çalıştırma desteği var, ama Vitest 5'teki hiyerarşik, devralımlı model daha yeni ve daha granüler bir monorepo mimarisi sunuyor — büyüyen bir Vite monorepo'da bu fark hissediliyor.

Ekosistem ataleti: React Native ve Metro

Jest'in en güçlü savunma hattı burada. React Native'in resmi dokümantasyonu açıkça şunu söylüyor: "React Native'in varsayılan şablonu Jest testing framework'üyle gelir, bu ortama özel ayarlanmış bir preset içerir." Bu, Jest'i RN ekosisteminde fiilen varsayılan seçim yapıyor; Expo'nun resmi dokümantasyonu da jest-expo preset'inin kurulumunu adım adım anlatıyor. Vitest ise Vite'ın transform pipeline'ına dayandığı için Metro bundler tabanlı React Native projelerinde first-party bir karşılığa sahip değil; bu araştırmada reactnative.dev dokümantasyonunda Vitest'e herhangi bir referans bulunamadı, çünkü Metro Vite tabanlı değil. Vitest'in Browser Mode sağlayıcı listesi de yalnızca Playwright, WebdriverIO ve preview'ı kapsıyor — RN/Metro için ayrı bir birinci sınıf sağlayıcı yok. Pratik sonuç: büyük, mevcut bir Jest suite'in varsa ve özellikle React Native/Metro'ya bağımlıysan, Vitest'e geçişin kazancı göç maliyetini karşılamayabilir. Bu senaryoda kademeli bir yol (yeni testler Vitest, mevcut suite Jest'te kalır) daha gerçekçi bir seçenek — brief'teki üçüncü yol hipotezini kaynaklar destekliyor.

Proje yaşı, lisans ve ekosistem büyüklüğü

Jest'in GitHub deposu (jestjs/jest) 10 Aralık 2013'te açıldı — Vitest'in vitest-dev/vitest deposu ise 3 Aralık 2021'de. Bu 8 yıllık fark yıldız sayılarına da yansıyor: Jest 45.467, Vitest 17.151 (yaklaşık 2,65 kat). İkisi de MIT lisanslı ve ücretsiz; ticari fiyat/plan tablosu yok. Yalnız yıldıza bakarsan tabloyu eksik okursun. Jest'in resmi ana sayfasındaki "Who uses Jest?" bölümü son bir ayda 100 milyondan fazla indirme ve GitHub'da 15 milyondan fazla açık depoda kullanım bildiriyor; şirket listesinde Facebook, Airbnb, Instagram, Spotify, Twitter ve The New York Times anılıyor, ayrıca projeyi aylık 3 dolar ve üzeri destekleyen 600'den fazla bağışçı var. Vitest tarafında eşdeğer bir "kimler kullanıyor" sayfasını taradığım sayfalarda (vitest.dev ana sayfası, /guide/ ve blog) bulamadım — bu asimetri ürün kalitesi değil, yayımlanan veri farkı. Sahiplik tarafında Jest, Meta (Facebook) bünyesinde doğdu ve 11 Mayıs 2022'deki resmi duyuruyla OpenJS Foundation üzerinden Jest Core ekibine devredildi. Vitest ise 790'dan fazla katkıcıya sahip, sürdürücüleri arasında Vite'ın yaratıcısı Evan You'nun da bulunduğu, OpenCollective bağışlarıyla finanse edilen bir proje.

Hangi Senaryoda Hangisi

Sıfırdan yeni bir Next.js/Vite/Nuxt web projesi kuruyorsun

Öneri: Vitest

Vite ve Nuxt tarafında aynı vite.config.js'i paylaşırsın; Next.js'te config ayrı kalır (derleyici Vite değil, ayrı bir vitest.config ve @vitejs/plugin-react kurarsın). Üçünde de ortak kazanç şu: native ESM/TS desteğini ek transform paketi kurmadan alıyorsun, üstüne Vitest 5'in ölçülmüş hız kazanımı biniyor.

React Native uygulaması geliştiriyorsun, Expo/Metro kullanıyorsun

Öneri: Jest

RN'in varsayılan şablonu Jest preset'iyle geliyor, Expo tarafında da resmi jest-expo preset'i var; Vitest'in first-party bir Metro/RN desteği yok.

10.000+ satırlık, çalışan bir Jest suite'in var, aktif geliştirme sürüyor

Öneri: Kademeli geçiş

Big-bang göçün riski, Vitest'in hız kazanımından daha ağır basabilir; yeni testleri Vitest'e yazıp eski suite'i Jest'te bırakmak daha düşük riskli.

Component/browser-level test yazman gerekiyor (gerçek DOM, gerçek tarayıcı)

Öneri: Vitest

Vitest'in first-party Browser Mode'u ve Vitest 5'teki Trace View, Jest'te olmayan bir yetenek; Jest bunun için ek araç (Cypress CT) gerektirir.

CI'da Node sürümü 20 veya altında sabitlenmiş, kısa vadede yükseltilemiyor

Öneri: Jest

Vitest 5'in engines alanı 22.12+/24.x/26+ istiyor (23.x ve 25.x dışarıda); Jest daha geniş bir Node aralığını (^18.14'ten itibaren) destekliyor.

Büyüyen bir monorepo'da birden fazla paket için test altyapısı kuruyorsun

Öneri: Vitest

Vitest 5'in nested project inheritance modeli ve -p filtreleme kısayolu, Jest'in --projects bayrağına göre daha granüler bir yapı sunuyor.

Ekibin Yarn kullanıyor ve paket yönetiminde minimum sürpriz istiyorsun

Öneri: Dikkatli Vitest

Vitest 5'te vite artık peer dependency; Yarn bunu otomatik kurmuyor, elle eklemen gerekiyor — aksi halde paket çözülemez.

Yaygın Tuzaklar

  • Vitest 5'e yükseltip clearMocks'un artık varsayılan true olduğunu fark etmemek

    Vitest 5

    Çözüm

    beforeAll/modül seviyesinde mock kuran testleri gözden geçir; gerekiyorsa test.clearMocks: false ile eski davranışa dön veya mock kurulumunu her testte tekrarla.

  • Yarn ile Vitest 5 kurup 'vite bulunamadı' hatası almak

    Vitest 5

    Çözüm

    vite artık peer dependency; Yarn otomatik kurmuyor, package.json'a elle vite bağımlılığı ekle.

  • Jest'te ESM projede --experimental-vm-modules bayrağını unutup import hatası almak

    Jest

    Çözüm

    Node'u bu bayrakla çalıştır ve transform yapılandırmasını (transform: {} veya ESM-uyumlu transformer) elle ayarla; Jest'in ESM desteği hâlâ deneysel.

  • Vitest'te test.sequential/describe.sequential kullanan eski kodu Vitest 5'e taşımak

    Vitest 5

    Çözüm

    Bu API'ler kaldırıldı; { concurrent: false } seçeneğiyle değiştir.

  • React Native projesinde Vitest'e geçmeyi denemek

    Vitest 5

    Çözüm

    Vitest'in Metro/RN için first-party desteği yok; RN tarafını Jest'te bırak, yalnız Vite tabanlı web/admin paketlerini Vitest'e geçir.

Geçiş Kılavuzu

Jest'ten Vitest 5'e (Vite tabanlı proje)

Tahmini süre: Orta ölçekli bir paket için 1-3 gün; büyük monorepo'da paket başına kademeli göçle 2-4 hafta
  1. 1Node'u 22.12+, 24.x ya da 26+ sürümlerinden birine yükselt ve Vite'ı ≥6.4.0'a güncelle (Vitest 5'in zorunlu ön koşulu; 23.x ve 25.x desteklenmiyor).
  2. 2npm install -D vitest @vitest/coverage-v8 ile kur; Yarn kullanıyorsan vite'ı elle bağımlılık olarak ekle (artık peer dependency).
  3. 3vite.config.js'e test: {} bloğu ekleyerek Jest'in ayrı config dosyasını (jest.config.js) kademeli olarak devre dışı bırak.
  4. 4Resmi 'Migrating from Jest' rehberinin ilk maddesini uygula: Jest'te varsayılan açık olan globals API Vitest'te kapalı — ya globals: true ayarını ekle ya da describe/it/expect'i vitest modülünden import et.
  5. 5jest.fn/jest.mock çağrılarını vi.fn/vi.mock ile değiştir; vi.mock yalnızca top-level'da çağrılabiliyor ve factory'si her export'u (default dahil) açıkça döndüren bir nesne vermeli.
  6. 6mockReset semantiğini gözden geçir: Jest mock'u boş fonksiyona döndürürken Vitest orijinal implementasyona döndürüyor; ayrıca clearMocks Vitest 5'te varsayılan true, beforeAll'da kurulan mock'ları doğrula.
  7. 7test.sequential/describe.sequential dosyalarını { concurrent: false } söz dizimine çevir ve coverage'ı @vitest/coverage-v8 (hız) veya @vitest/coverage-istanbul (ayrıntılı rapor) ile yeniden kur.
  8. 8Bir pakette (en riskli olmayanında) göçü tamamla, CI'da yeşil aldıktan sonra diğer paketlere yay; React Native/Metro paketlerini Jest'te bırak.

Gelecek Öngörüsü

Vitest 5

Vitest 5, 790+ katkıcı ve Vite ekibinin doğrudan desteğiyle hızla büyüyor; nested project ve browser mode yatırımları (Trace View) Vite ekosisteminin genişlemesine paralel ilerliyor. Resmi bir sonraki majör sürüm için tarihli bir yol haritası bu araştırmada bulunamadı.

Jest

Jest 30.5.2'deki Node yerleşik TS-strip desteği, ekibin ESM/TS transform yükünü azaltmaya devam ettiğini gösteriyor. OpenJS Foundation şemsiyesi ve React Native'deki varsayılan konumu, kısa vadede projenin sürdürülebilirliğini güvence altına alıyor. Tarihli bir resmi yol haritası bu araştırmada bulunamadı.

Altın Bilgi

En değerli çıkarım şu: "Vitest mi Jest mi" sorusu, "kendi projemde ölçtüm mü" sorusundan daha az önemli. Vitest 5'in kendi resmi tablosu bile geniş bir aralık veriyor — senaryoya göre %8'den %53'e — ve blog açıkça, ortam kurulumunun baskın olduğu yapılandırmalarda farkın ±%3 bandında kaldığını söylüyor. Blog rakamına değil, kendi CI'ında kendi senaryonla aldığın ölçüme güven. İkinci nokta: bu bir "ya o ya bu" kararı olmak zorunda değil. Vitest'in Jest uyumlu mocking API'si ve iki aracın da desteklediği çoklu-proje modelleri sayesinde, aynı repo içinde bir paket Jest'te (örneğin React Native app'i) kalırken diğerleri Vitest'e geçebilir. Göçü big-bang değil, paket paket düşün.

İlgili Blog Yazıları

Tüm Yazıları Gör

İlgili Projeler

Tüm Projeleri Gör

İlgili İçerik