Vitest 3.2 Çıktı!
2 Haziran 2025

Vitest 3.2, Tarayıcı Modu ve TypeScript desteğindeki iyileştirmelere odaklanmaktadır. Bu sürüm ayrıca bazı yeni ve kullanışlı metotlar ile yapılandırma seçenekleri sunmakta ve workspace yapılandırmasını projects lehine kullanımdan kaldırmaktadır.
workspace Kullanımdan Kaldırıldı
Yapılandırmayı basitleştirme çabasıyla ekip, ayrı vitest.workspace dosyasını kullanımdan kaldırmaya ve kök yapılandırmada yalnızca projects seçeneğini kullanmayı önermeye karar vermiştir. Bu yaklaşım, genel seçeneklerin yapılandırılmasını da kolaylaştırmaktadır (çünkü kök yapılandırmanız olmadığında raporlayıcıları nasıl ekleyeceğinizi düşünmenize gerek kalmaz).
Ayrıca workspace adını kullanımdan kaldırmaya karar verdik çünkü PNPM gibi monorepo desteği sağlayan diğer araçlarla çakışmaktadır. Vitest bu projeleri ayrı CWD (mevcut çalışma dizini) ile çalıştırmaz; aksine onları bağımsız Vitest örnekleri gibi değerlendirir. Bu durum, diğer araçların işleyişini etkilemeden monorepolar için daha iyi bir çözüm geliştirmemiz adına bize daha fazla esneklik sağlamaktadır.
Bu seçenek, gelecekteki büyük bir sürümde tamamen kaldırılacak ve projects ile değiştirilecektir. O zamana kadar, çalışma alanı özelliği kullanılırsa Vitest bir uyarı mesajı gösterecektir.
import { defineConfig } from "vitest/config";
export default defineConfig({
test: {
// "test.workspace" özelliği artık "test.projects" olarak yeniden adlandırıldı
workspace: [
projects: [
{ test: { name: "Unit" } },
{ test: { name: "Integration" } },
],
},
});Açıklama API'si
Yeni açıklama API'si, herhangi bir testi özel bir mesaj ve ek bilgi ile açıklamanıza olanak tanır. Bu açıklamalar UI, HTML, JUnit, TAP ve GitHub Actions raporlayıcılarında görünür. Vitest ayrıca test başarısız olursa CLI'da ilgili açıklamayı yazdıracaktır.

Kapsamı Belirlenmiş Fixture'lar
test.extend fixture'ları artık scope seçeneğini file veya worker olarak belirleyebilir:
const test = baseTest.extend({
db: [
async ({}, use) => {
// ...kurulum
await use(db);
await db.close();
},
{ scope: 'worker' },
],
});file kapsamındaki bir fixture, dosyanın en üst düzeyinde beforeAll ve afterAll kullanmaya benzer, ancak fixture herhangi bir testte kullanılmadığı takdirde çağrılmaz.
worker kapsamındaki bir fixture her worker için bir kez başlatılır. Ancak, varsayılan olarak Vitest'in her test için bir worker oluşturduğunu unutmayın; bu nedenle bu avantajdan yararlanmak için izolasyonu devre dışı bırakmanız gerekir.
Özel Proje Adı Renkleri
Artık projects kullanırken özel bir renk ayarlayabilirsiniz:
Yapılandırma Örneği
export default defineConfig({
test: {
projects: [
{
test: {
name: {
label: 'unit',
color: 'red',
},
},
},
{
test: {
name: {
label: 'browser',
color: 'green',
},
browser: {
enabled: true,
provider: 'playwright',
instances: [{ browser: 'chromium' }],
},
},
},
],
},
})
Özel Tarayıcı Konum Belirleyici API'si
Yerleşik konum belirleyiciler, uygulamanızın ihtiyaçlarını karşılamak için yeterli olmayabilir. CSS kullanmaya geri dönmek ve Vitest'in konum belirleyici API'si aracılığıyla sağladığı yeniden deneme korumasını kaybetmek yerine, artık yeni locators.extend API'sini kullanarak konum belirleyicileri genişletmenizi öneriyoruz.
import { locators } from '@vitest/browser/context';
locators.extend({
getByCommentsCount(count: number) {
return `.comments :text("${count} comments")`;
},
});Yeni bir konum belirleyici oluşturmak için bir Playwright konum belirleyici dizesi döndürün. Bu yöntemden döndürülen dizenin, bir üst konum belirleyici varsa, o üst konum belirleyicinin kapsamına alınacağını unutmayın.
Artık getByCommentsCount'u page veya başka herhangi bir konum belirleyici üzerinde doğrudan çağırabilirsiniz:
await expect.element(page.getByCommentsCount(1)).toBeVisible();
await expect
.element(
page.getByRole('article', { name: 'Hello World' }).getByCommentsCount(1)
)
.toBeVisible();Bu yöntem bir dize döndürürse, dönüş değeri bir konum belirleyiciye dönüştürülecek, böylece zincirlemeye devam edebilirsiniz:
page
.getByRole('article', { name: 'Hello World' })
.getByCommentsCount(1)
.getByText('comments');Bu yöntem, bir bağlam varsa (yöntem page üzerinde çağrılırsa, bağlam page'i ifade edecektir) mevcut konum belirleyici bağlamına erişebilir, böylece tüm konum belirleyici yöntemlerini bu bağlamda zincirleyebilirsiniz:
import { locators } from '@vitest/browser/context';
import type { Locator } from '@vitest/browser/context';
locators.extend({
getByCommentsCount(this: Locator, count: number) {
return this.getByRole('comment').and(this.getByText(`${count} comments`));
},
});Bağlama erişiminiz olması, özel bir kullanıcı olayı tanımlamak için konum belirleyicinin normal yöntemlerini çağırmanıza da olanak tanır:
import { locators, page } from '@vitest/browser/context';
import type { Locator } from '@vitest/browser/context';
locators.extend({
clickAndFill(this: Locator, text: string) {
await this.click();
await this.fill(text);
},
});
await page.getByRole('textbox').clickAndFill('Hello World');Daha fazla bilgi için lütfen locators.extend API'sine bakın.
vi.spyOn ve vi.fn'de Açık Kaynak Yönetimi
Açık Kaynak Yönetimi desteği olan ortamlarda, içeren bloktan çıkıldığında herhangi bir sahte fonksiyonda mockRestore'u otomatik olarak çağırmak için const yerine using kullanabilirsiniz. Bu, özellikle izlenen yöntemler için kullanışlıdır:
it('calls console.log', () => {
using spy = vi.spyOn(console, 'log').mockImplementation(() => {})
debug('message')
expect(spy).toHaveBeenCalled()
})
// console.log burada geri yüklenirTest signal API'si
Vitest artık test gövdesine bir AbortSignal nesnesi sağlamaktadır. Bu Web API'sini destekleyen herhangi bir kaynağı durdurmak için kullanabilirsiniz.
Sinyal, test zaman aşımına uğradığında, başka bir test başarısız olduğunda ve --bail bayrağı sıfır olmayan bir değere ayarlandığında veya kullanıcı terminalde Ctrl+C'ye bastığında iptal edilir.
Örneğin, testler kesintiye uğradığında bir fetch isteğini durdurabilirsiniz:
it('stop request when test times out', async ({ signal }) => {
await fetch('/heavy-resource', { signal });
}, 2000);Kapsam V8 AST-Duyarlı Yeniden Eşleme
Vitest artık Vitest bakımcılarından AriPerkkio tarafından geliştirilen ast-v8-to-istanbul paketini kullanmaktadır. Bu, v8 kapsama raporunu Istanbul ile uyumlu hale getirir ve daha iyi bir performans sunar. Bu özelliği coverage.experimentalAstAwareRemapping değerini true olarak ayarlayarak etkinleştirin.
Bunu bir sonraki ana sürümde varsayılan yeniden eşleme modu yapmayı planlıyoruz. Eski v8-to-istanbul tamamen kaldırılacaktır. Tartışmaya https://github.com/vitest-dev/vitest/issues/7928 adresinden katılmaktan çekinmeyin.
watchTriggerPatterns Seçeneği
Bir dosyayı düzenlediğinizde, Vitest yalnızca bu dosyayı içe aktaran testleri yeniden çalıştırmak için yeterince akıllıdır. Ne yazık ki, Vitest statik analizi yalnızca statik ve dinamik import ifadelerini dikkate alır. Bir dosyayı okuduğunuzda veya ayrı bir işlem başlattığınızda, Vitest ilgili dosyalardaki değişiklikleri göz ardı edecektir.
watchTriggerPatterns seçeneği ile, değişen dosyaya bağlı olarak hangi testlerin yeniden çalıştırılacağını yapılandırabilirsiniz. Örneğin, bir şablon değiştiğinde mailers testlerini her zaman yeniden çalıştırmak için bir tetikleyici deseni ekleyin:
export default defineConfig({
test: {
watchTriggerPatterns: [
{
pattern: /^src\/templates\/(.*)\.(ts|html|txt)$/,
testsToRun: (file, match) => {
return `api/tests/mailers/${match[2]}.test.ts`;
},
},
],
},
});Yeni Çok Amaçlı Matchers Tipi
Vitest artık tüm özel eşleştiricileriniz için tek bir yerde tür desteği eklemek üzere genişletebileceğiniz bir Matchers tipine sahiptir. Bu tip, tüm bu kullanım durumlarını etkiler:
expect().to*expect.to*expect.extend({ to* })
Örneğin, tür güvenli bir toBeFoo eşleştiricisine sahip olmak için şöyle bir şey yazabilirsiniz:
import { expect } from 'vitest';
interface CustomMatchers<R = unknown> {
toBeFoo: (arg: string) => R;
}
declare module 'vitest' {
interface Matchers<T = any> extends CustomMatchers<T> {}
}
expect.extend({
toBeFoo(actual, arg) {
// ^?
// ... uygulama
return {
pass: true,
message: () => '',
};
},
});
expect('foo').toBeFoo('foo');
expect.toBeFoo('foo');sequence.groupOrder
Yeni sequence.groupOrder seçeneği, birden fazla proje kullanırken projenin testlerini çalıştırma sırasını kontrol eder.
- Aynı grup sıra numarasına sahip projeler birlikte çalışacak ve gruplar en düşükten en yükseğe doğru çalıştırılır.
- Bu seçeneği ayarlamadığınız takdirde, tüm projeler paralel olarak çalışır.
- Birkaç proje aynı grup sırasını kullanıyorsa, aynı anda çalışır.
Örnek
Bu örneği ele alalım:
import { defineConfig } from 'vitest/config';
export default defineConfig({
test: {
projects: [
{
test: {
name: 'slow',
sequence: {
groupOrder: 0,
},
},
},
{
test: {
name: 'fast',
sequence: {
groupOrder: 0,
},
},
},
{
test: {
name: 'flaky',
sequence: {
groupOrder: 1,
},
},
},
],
},
});Bu projelerdeki testler şu sırayla çalışacaktır:
0. slow |
|> Paralel çalışır
0. fast |
1. flaky |> Slow ve fast'ten sonra tek başına çalışırDeğişikliklerin tam listesi Vitest 3.2 Değişiklik Günlüğü adresindedir.