Projekty testowe

Przykładowy projekt

GitHub - Wypróbuj online

WARNING

Funkcja ta była wcześniej znana jako workspace. Od wersji 3.2 workspace jest przestarzały i został zastąpiony konfiguracją projects. Obie nazwy odnoszą się do tej samej funkcjonalności.

Vitest umożliwia definiowanie wielu konfiguracji projektów w ramach jednego procesu Vitest. Ta funkcja jest szczególnie przydatna w konfiguracjach monorepo, ale może być również używana do uruchamiania testów z różnymi ustawieniami, takimi jak resolve.alias, plugins lub test.browser i innymi.

Definiowanie projektów

Możesz zdefiniować projekty w swojej głównej konfiguracji:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    projects: ['packages/*'],
  },
});

Konfiguracje projektów mogą być definiowane jako konfiguracje inline, pliki lub wzorce glob odwołujące się do twoich projektów. Na przykład, jeśli masz folder o nazwie packages, który zawiera twoje projekty, możesz zdefiniować tablicę w swoim głównym pliku konfiguracyjnym Vitest:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    projects: ['packages/*'],
  },
});

Vitest będzie traktować każdy folder w packages jako oddzielny projekt, nawet jeśli nie zawiera pliku konfiguracyjnego. Jeśli ten wzorzec glob pasuje do dowolnego pliku, zostanie on uznany za konfigurację Vitest, nawet jeśli nie ma vitest w nazwie lub ma nietypowe rozszerzenie pliku.

WARNING

Vitest nie traktuje pliku vitest.config na poziomie głównym jako projektu, chyba że jest on wyraźnie określony w konfiguracji. W konsekwencji, konfiguracja na poziomie głównym będzie wpływać tylko na opcje globalne, takie jak reporters i coverage. Warto zauważyć, że Vitest zawsze uruchamia pewne punkty zaczepienia wtyczek, takie jak apply, config, configResolved lub configureServer, określone w głównym pliku konfiguracyjnym. Vitest używa również tych samych wtyczek do wykonywania globalnych ustawień i niestandardowego dostawcy pokrycia.

Możesz również odwoływać się do projektów za pomocą ich plików konfiguracyjnych:

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    projects: ['packages/*/vitest.config.{e2e,unit}.ts'],
  },
});

Ten wzorzec uwzględni tylko projekty, których nazwa zawiera e2e lub unit przed rozszerzeniem.

Możesz również definiować projekty za pomocą konfiguracji inline. Konfiguracja obsługuje obie składnie jednocześnie.

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    projects: [
      // dopasowuje każdy folder i plik w folderze `packages`
      'packages/*',
      {
        // dodaj "extends: true", aby dziedziczyć opcje z konfiguracji na poziomie głównym
        extends: true,
        test: {
          include: ['tests/**/*.{browser}.test.{ts,js}'],
          // zaleca się podanie nazwy podczas używania konfiguracji inline
          name: 'happy-dom',
          environment: 'happy-dom',
        },
      },
      {
        test: {
          include: ['tests/**/*.{node}.test.{ts,js}'],
          // kolor etykiety nazwy można zmienić
          name: { label: 'node', color: 'green' },
          environment: 'node',
        },
      },
    ],
  },
});

WARNING

Wszystkie projekty muszą mieć unikalne nazwy; w przeciwnym razie Vitest wyrzuci błąd. Jeśli nazwa nie zostanie podana w konfiguracji inline, Vitest przypisze numer. Dla konfiguracji projektów zdefiniowanych za pomocą składni glob, Vitest domyślnie użyje właściwości "name" w najbliższym pliku package.json lub, w przypadku jego braku, nazwy folderu.

Projekty nie obsługują wszystkich właściwości konfiguracyjnych. Dla lepszej kontroli typów, użyj metody defineProject zamiast defineConfig w plikach konfiguracyjnych projektu:

// @errors: 2769
import { defineProject } from 'vitest/config';

export default defineProject({
  test: {
    environment: 'jsdom',
    // "reporters" nie jest obsługiwane w konfiguracji projektu,
    // więc pokaże błąd
    reporters: ['json'],
  },
});

Uruchamianie testów

Aby uruchomić testy, zdefiniuj skrypt w pliku package.json w głównym katalogu projektu:

{
  "scripts": {
    "test": "vitest"
  }
}

Teraz testy można uruchomić przy użyciu menedżera pakietów:

npm

npm run test

yarn

yarn test

pnpm

pnpm run test

bun

bun run test

Jeśli musisz uruchomić testy tylko w jednym projekcie, użyj opcji CLI --project:

npm

npm run test --project e2e

yarn

yarn test --project e2e

pnpm

pnpm run test --project e2e

bun

bun run test --project e2e

TIP

Opcja CLI --project może być używana wielokrotnie, aby filtrować wiele projektów:

npm

npm run test --project e2e --project unit

yarn

yarn test --project e2e --project unit

pnpm

pnpm run test --project e2e --project unit

bun

bun run test --project e2e --project unit

Konfiguracja

Domyślnie żadne opcje konfiguracyjne nie są dziedziczone z konfiguracji na poziomie głównym. Możesz utworzyć wspólny plik konfiguracyjny i połączyć go ręcznie z konfiguracją projektu:

import { defineProject, mergeConfig } from 'vitest/config';
import configShared from '../vitest.shared.js';

export default mergeConfig(
  configShared,
  defineProject({
    test: {
      environment: 'jsdom',
    },
  })
);

Dodatkowo, można użyć opcji extends, aby dziedziczyć z konfiguracji na poziomie głównym. Wszystkie opcje zostaną połączone.

import { defineConfig } from 'vitest/config';
import react from '@vitejs/plugin-react';

export default defineConfig({
  plugins: [react()],
  test: {
    pool: 'threads',
    projects: [
      {
        // odziedziczy opcje z tej konfiguracji, takie jak wtyczki i pula
        extends: true,
        test: {
          name: 'unit',
          include: ['**/*.unit.test.ts'],
        },
      },
      {
        // nie będzie dziedziczyć żadnych opcji z tej konfiguracji
        // jest to domyślne zachowanie
        extends: false,
        test: {
          name: 'integration',
          include: ['**/*.integration.test.ts'],
        },
      },
    ],
  },
});

Nieobsługiwane opcje

Niektóre opcje konfiguracyjne nie są dozwolone w konfiguracji projektów. Do najważniejszych należą:

• coverage: pokrycie kodu jest obliczane dla całego procesu
• reporters: obsługiwani są tylko reporterzy na poziomie głównym
• resolveSnapshotPath: uwzględniany jest tylko resolver z poziomu głównego
• wszystkie inne opcje, które nie wpływają na uruchamianie testów

Wszystkie opcje konfiguracyjne, które nie są obsługiwane w konfiguracji projektu, są oznaczone znakiem * w przewodniku "Konfiguracja". Należy je zdefiniować jednokrotnie w głównym pliku konfiguracyjnym.