Megjelent a Vitest 3.2!

2025. június 2.

A Vitest 3.2 a böngészőmód és a TypeScript-támogatás fejlesztésére összpontosít. Ez a kiadás néhány új, hasznos metódust és konfigurációs opciót is tartalmaz, továbbá a workspace konfigurációt a projects opció javára elavulttá teszi.

A workspace elavult

A konfiguráció egyszerűsítése érdekében a csapat úgy döntött, hogy elavulttá teszi a különálló vitest.workspace fájlt, és azt javasolja, hogy csak a projects opciót használják a gyökérkonfigurációban. Ez a globális opciók konfigurálását is leegyszerűsíti (mivel nem kell kitalálni, hogyan adjunk hozzá riportolókat, ha nincs gyökérkonfiguráció).

Azt is úgy döntöttünk, hogy elavulttá tesszük a workspace nevet, mert ütközik más eszközökkel, mint például a PNPM, amelyek szintén ezzel az opcióval biztosítanak monorepo támogatást. A Vitest nem futtatja ezeket a projekteket külön CWD-vel, hanem inkább al-Vitest projektekként kezeli őket. Ez lehetőséget ad arra, hogy jobb megoldást találjunk a monorepókra anélkül, hogy mások működését megzavarnánk.

Ez az opció egy jövőbeli főverzióban teljesen eltávolításra kerül, és a projects váltja fel. Addig is a Vitest figyelmeztetést fog kiírni, ha a workspace funkciót használják.

import { defineConfig } from "vitest/config";
export default defineConfig({
  test: {
    // "test.workspace" helyett "test.projects"
    workspace: [ 
    projects: [ 
      { test: { name: "Unit" } },
      { test: { name: "Integration" } },
    ],
  },
});

Annotációs API

Az új annotációs API lehetővé teszi, hogy bármely tesztet egyéni üzenettel és melléklettel annotáljon. Ezek az annotációk láthatók a felhasználói felületen, HTML-ben, junit, tap és GitHub Actions riportolókban. A Vitest a kapcsolódó annotációt a CLI-ben is megjeleníti, ha a teszt sikertelen.

Hatókörrel rendelkező Fixture-ök

A test.extend fixture-ök mostantól megadhatják a scope opciót: file vagy worker.

const test = baseTest.extend({
  db: [
    async ({}, use) => {
      // ...beállítás
      await use(db);
      await db.close();
    },
    { scope: 'worker' },
  ],
});

A fájl fixture hasonló a beforeAll és afterAll használatához a fájl gyökerében, de nem hívódik meg, ha a fixture-t egyetlen tesztben sem használják.

A worker fixture worker scope-onként egyszer inicializálódik, de vegye figyelembe, hogy alapértelmezés szerint a Vitest minden teszthez egy munkavégzőt hoz létre, ezért le kell tiltania az izolációt, hogy kihasználhassa a benne rejlő előnyöket.

Egyéni projektnevek színei

Mostantól egyéni színt állíthat be a projects használatakor:

Konfigurációs példa

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' }],
          },
        },
      },
    ],
  },
})

Egyéni böngésző locator API

A beépített locatorok nem feltétlenül elegendőek az alkalmazás igényeinek kielégítésére. Ahelyett, hogy CSS-t használnánk, és elveszítenénk az újrafuttathatósági védelmet, amelyet a Vitest a locator API-ján keresztül biztosít, most azt javasoljuk, hogy bővítsük a locatorokat az új locators.extend API használatával.

import { locators } from '@vitest/browser/context';

locators.extend({
  getByCommentsCount(count: number) {
    return `.comments :text("${count} comments")`;
  },
});

Adjon vissza egy Playwright locator stringet egy új locator létrehozásához. Vegye figyelembe, hogy az ebből a metódusból visszaadott string a szülő locatorra lesz hatókörözve, amennyiben létezik.

Mostantól közvetlenül hívhatja a getByCommentsCount metódust a page-en vagy bármely más locatoron:

await expect.element(page.getByCommentsCount(1)).toBeVisible();
await expect
  .element(
    page.getByRole('article', { name: 'Hello World' }).getByCommentsCount(1)
  )
  .toBeVisible();

Ha ez a metódus stringet ad vissza, akkor a visszatérési érték locatorrá konvertálódik, így folytathatja a láncolást:

page
  .getByRole('article', { name: 'Hello World' })
  .getByCommentsCount(1)
  .getByText('comments');

Ez a metódus hozzáfér az aktuális locator kontextushoz (ha a metódust a page-en hívják, akkor a kontextus a page-re fog hivatkozni), így az összes locator metódust láncolhatja:

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`));
  },
});

A kontextushoz való hozzáférés lehetővé teszi a locator szokásos metódusainak hívását is egy egyéni felhasználói esemény definiálásához:

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');

További információkért tekintse meg a locators.extend API-t.

Explicit erőforrás-kezelés a vi.spyOn és vi.fn metódusokban

Azokban a környezetekben, amelyek támogatják az Explicit erőforrás-kezelést, a using kulcsszót használhatja a const helyett, hogy automatikusan meghívja a mockRestore metódust bármely mockolt függvényen, amikor a tartalmazó blokk kilép. Ez különösen hasznos a spy-olt metódusok esetében:

it('calls console.log', () => {
  using spy = vi.spyOn(console, 'log').mockImplementation(() => {})
  debug('message')
  expect(spy).toHaveBeenCalled()
})

// a console.log itt visszaállítódik

Teszt signal API

A Vitest mostantól egy AbortSignal objektumot biztosít a teszt törzsének. Ezt használhatja bármely erőforrás leállítására, amely támogatja ezt a Web API-t.

A jel megszakad, ha a teszt időtúllép, egy másik teszt sikertelen, és a --bail flag nem nulla értékre van állítva, vagy a felhasználó megnyomja a Ctrl+C billentyűkombinációt a terminálban.

Például leállíthat egy fetch kérést, ha a tesztek megszakadnak:

it('stop request when test times out', async ({ signal }) => {
  await fetch('/heavy-resource', { signal });
}, 2000);

Lefedettség V8 AST-alapú átképezése

A Vitest mostantól az ast-v8-to-istanbul csomagot használja, amelyet a Vitest egyik karbantartója, AriPerkkio fejlesztett ki. Ez a v8 lefedettségi riportot az istanbullal kompatibilissé teszi, miközben jobb teljesítményt nyújt! Engedélyezze ezt a funkciót a coverage.experimentalAstAwareRemapping true értékre állításával.

Azt tervezzük, hogy ez lesz az alapértelmezett átképezési mód a következő főverzióban. A régi v8-to-istanbul teljesen eltávolításra kerül. Nyugodtan csatlakozzon a vitához a https://github.com/vitest-dev/vitest/issues/7928 címen.

watchTriggerPatterns opció

Amikor szerkeszt egy fájlt, a Vitest intelligensen csak azokat a teszteket futtatja újra, amelyek importálják ezt a fájlt. Sajnos a Vitest statikus elemzése csak a statikus és dinamikus import utasításokat veszi figyelembe. Ha egy fájl olvasása vagy külön folyamat indítása történik, a Vitest figyelmen kívül hagyja a kapcsolódó fájlok változásait.

A watchTriggerPatterns opcióval konfigurálhatja, hogy mely teszteket futtassa újra a megváltozott fájltól függően. Például, a mailers tesztek mindig újra futtatásához, amikor egy sablon megváltozik, adjon hozzá egy trigger mintát:

export default defineConfig({
  test: {
    watchTriggerPatterns: [
      {
        pattern: /^src\/templates\/(.*)\.(ts|html|txt)$/,
        testsToRun: (file, match) => {
          return `api/tests/mailers/${match[2]}.test.ts`;
        },
      },
    ],
  },
});

Az új, többféle célra használható Matchers típus

A Vitest mostantól rendelkezik egy Matchers típussal, amelyet kiterjeszthet, hogy egy helyen biztosítsa a típus támogatását az összes egyéni matcheréhez. Ez a típus az összes alábbi felhasználási esetre vonatkozik:

• expect().to*
• expect.to*
• expect.extend({ to* })

Például, egy típusbiztos toBeFoo matcherhez valami ilyesmit írhat:

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) {
    //            ^?
    // ... implementáció
    return {
      pass: true,
      message: () => '',
    };
  },
});

expect('foo').toBeFoo('foo');
expect.toBeFoo('foo');

sequence.groupOrder

Az új sequence.groupOrder opció szabályozza a tesztek futtatási sorrendjét több projekt használatakor.

• Az azonos csoportrendezési számmal rendelkező projektek együtt futnak, a csoportok pedig a legalacsonyabbtól a legmagasabbig kerülnek végrehajtásra.
• Ha ez az opció nincs beállítva, az összes projekt párhuzamosan fut.
• Ha több projekt azonos csoportrendezési számmal rendelkezik, akkor egyszerre futnak.

Példa

Tekintsük ezt a példát:

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,
          },
        },
      },
    ],
  },
});

A tesztek ezekben a projektekben ebben a sorrendben fognak lefutni:

 0. slow  |
          |> együtt futnak
 0. fast  |

 1. flaky |> a slow és fast után fut egyedül

---

A változások teljes listája a Vitest 3.2 Changelog oldalon található.