Vitest 3.2 je vydán!

2. června 2025

Vitest 3.2 se zaměřuje na vylepšení režimu prohlížeče a podporu TypeScriptu. Tato verze také obsahuje některé nové užitečné metody, možnosti konfigurace a nahrazuje konfiguraci workspace možností projects.

workspace je zastaralý

Ve snaze zjednodušit konfiguraci se tým rozhodl upustit od samostatného souboru vitest.workspace a doporučit používat pouze možnost projects v kořenové konfiguraci. To také zjednodušuje konfiguraci globálních možností (protože nemusíte hádat, jak přidat reportéry, když nemáte kořenovou konfiguraci).

Také jsme se rozhodli upustit od názvu workspace, protože koliduje s jinými nástroji, jako je PNPM, které poskytují podporu monorepo prostřednictvím této možnosti. Vitest nespouští tyto projekty s odděleným CWD a zachází s nimi spíše jako s dílčími instancemi Vitestu. Také nám to dává více prostoru pro nalezení lepšího řešení pro monorepos, aniž bychom narušili stávající funkčnost.

Tato možnost bude v budoucí hlavní verzi zcela odstraněna a nahrazena projects. Do té doby Vitest vytiskne varování, pokud je použita funkce workspace.

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

Anotační API

Nové anotační API vám umožňuje anotovat jakýkoli test vlastní zprávou a přílohou. Tyto anotace jsou viditelné v uživatelském rozhraní, HTML, JUnit, TAP a reportérech GitHub Actions. Vitest také vytiskne související anotaci v CLI, pokud test selže.

Scoped Fixtures

Fixtures test.extend nyní mohou specifikovat možnost scope: buď file nebo worker.

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

Fixture souboru je podobná použití beforeAll a afterAll na úrovni souboru, ale nebude volána, pokud fixture není použita v žádném testu.

Fixture worker je inicializována jednou na worker, ale mějte na paměti, že Vitest ve výchozím nastavení vytváří jednoho workeru pro každý test, takže musíte deaktivovat izolaci, abyste z toho měli prospěch.

Vlastní barvy názvů projektů

Nyní můžete nastavit vlastní barvu při použití projects:

Příklad konfigurace

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

Custom Browser Locators API

Vestavěné lokátory nemusí stačit k vyjádření potřeb vaší aplikace. Místo toho, abyste se vraceli k CSS a ztráceli ochranu proti opakování, kterou Vitest poskytuje prostřednictvím svého locator API, nyní doporučujeme rozšířit lokátory pomocí nového locators.extend API.

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

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

Vraťte Playwright locator string pro vytvoření nového lokátoru. Všimněte si, že řetězec vrácený touto metodou bude vázán na rodičovský lokátor, pokud existuje.

Nyní můžete volat getByCommentsCount na page nebo jakémkoli jiném lokátoru přímo:

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

Pokud tato metoda vrátí řetězec, pak se návratová hodnota převede na lokátor, takže ji můžete řetězit dál:

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

Tato metoda má přístup k aktuálnímu kontextu lokátoru, pokud existuje (pokud je metoda volána na page, pak kontext odkazuje na page), takže můžete řetězit všechny metody lokátoru uvnitř:

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

Přístup ke kontextu vám také umožňuje volat běžné metody lokátoru pro definování vlastní uživatelské události:

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

Další informace naleznete v locators.extend API.

Explicitní správa zdrojů v vi.spyOn a vi.fn

V prostředích, která podporují Explicit Resource Management, můžete použít using namísto const k automatickému volání mockRestore u jakékoli mockované funkce při opuštění obsahujícího bloku. To je obzvláště užitečné pro špehované metody:

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

// console.log je zde obnoven

Test signal API

Vitest nyní poskytuje objekt AbortSignal tělu testu. Můžete jej použít k zastavení jakéhokoli zdroje, který podporuje toto Web API.

Signál je zrušen, když test vyprší časový limit, jiný test selže a --bail flag je nastaven na nenulovou hodnotu, nebo uživatel stiskne Ctrl+C v terminálu.

Například můžete zastavit požadavek fetch, když jsou testy přerušeny:

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

Pokrytí V8 AST-aware remapping

Vitest nyní používá balíček ast-v8-to-istanbul vyvinutý jedním z udržovatelů Vitestu, AriPerkkio. To přináší zprávu o pokrytí v8 do souladu s istanbul, ale má lepší výkon! Tuto funkci povolíte nastavením coverage.experimentalAstAwareRemapping na true.

Plánujeme, aby se toto stalo výchozím režimem přemapování v příští hlavní verzi. Starý v8-to-istanbul bude zcela odstraněn. Neváhejte se připojit k diskusi na https://github.com/vitest-dev/vitest/issues/7928.

Možnost watchTriggerPatterns

Při úpravě souboru je Vitest dostatečně inteligentní, aby znovu spustil jen testy, které tento soubor importují. Bohužel, statická analýza Vitestu bere v úvahu pouze statické a dynamické příkazy import. Pokud čtete soubor nebo spouštíte samostatný proces, Vitest bude ignorovat změny v souvisejících souborech.

Pomocí možnosti watchTriggerPatterns můžete konfigurovat, které testy se mají znovu spustit podle změněného souboru. Například, chcete-li vždy znovu spustit testy mailers, když je změněna šablona, přidejte vzor spouštěče:

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

Nový víceúčelový typ Matchers

Vitest nyní disponuje typem Matchers, který můžete rozšířit pro přidání typové podpory pro všechny vaše vlastní matchery na jednom místě. Tento typ pokrývá všechny tyto případy použití:

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

Například, pro typově bezpečný porovnávač toBeFoo, můžete napsat něco takového:

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

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

sequence.groupOrder

Nová možnost sequence.groupOrder řídí pořadí, ve kterém projekty spouštějí své testy při použití více projektů.

• Projekty se stejným číslem pořadí skupiny se spustí společně a skupiny se spouštějí od nejnižšího čísla po nejvyšší.
• Pokud tuto možnost nezadáte, všechny projekty se spustí paralelně.
• Pokud několik projektů používá stejné pořadí skupiny, budou spuštěny současně.

Příklad

Zde je příklad:

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

Testy v těchto projektech se provedou v následujícím pořadí:

 0. slow  |
          |> běží současně
 0. fast  |

 1. flaky |> běží po dokončení slow a fast, samostatně

---

Kompletní seznam změn naleznete v Vitest 3.2 Changelog.