Częste błędy

Nie można znaleźć modułu './relative-path'

Jeśli podczas uruchamiania testów pojawi się błąd informujący o niemożności znalezienia modułu, może to wynikać z kilku przyczyn:

• 1. Błędnie wpisana ścieżka. Upewnij się, że ścieżka do modułu jest poprawna.
• 2. Użycie baseUrl w tsconfig.json. Vite domyślnie nie uwzględnia konfiguracji tsconfig.json. Jeśli polegasz na baseUrl do rozwiązywania ścieżek, konieczne może być zainstalowanie pakietu vite-tsconfig-paths.

import { defineConfig } from 'vitest/config';
import tsconfigPaths from 'vite-tsconfig-paths';

export default defineConfig({
  plugins: [tsconfigPaths()],
});

Alternatywnie, zmień ścieżkę importu tak, aby nie była względna względem katalogu głównego projektu:

- import helpers from 'src/helpers'
+ import helpers from '../src/helpers'

• 3. Nieprawidłowe użycie aliasów względnych. Vite traktuje aliasy jako względne względem pliku, w którym znajduje się import, a nie względem katalogu głównego projektu. Upewnij się, że aliasy są poprawnie skonfigurowane.

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    alias: {
      '@/': './src/', 
      '@/': new URL('./src/', import.meta.url).pathname, 
    },
  },
});

Nie można mockować "./mocked-file.js", ponieważ jest już załadowany

Ten błąd pojawia się, gdy metoda vi.mock jest wywoływana dla modułu, który został już załadowany. Vitest zgłasza ten błąd, ponieważ takie wywołanie nie przyniesie żadnego efektu – moduły z pamięci podręcznej mają pierwszeństwo.

Należy pamiętać, że vi.mock jest zawsze podnoszony (hoisted). Oznacza to, że moduł został załadowany, zanim plik testowy zaczął się wykonywać, najprawdopodobniej w pliku konfiguracyjnym (setup file). Aby rozwiązać ten problem, usuń import lub wyczyść pamięć podręczną na końcu pliku konfiguracyjnego. Pamiętaj, że w takim przypadku plik konfiguracyjny i plik testowy będą odwoływać się do różnych instancji modułów.

// setupFile.js
import { vi } from 'vitest';
import { sideEffect } from './mocked-file.js';

sideEffect();

vi.resetModules();

Nie udało się zakończyć pracy workera

Ten błąd może wystąpić, gdy funkcja fetch z NodeJS jest używana z domyślnym ustawieniem pool: 'threads'. Problem ten jest śledzony w zgłoszeniu Timeout abort can leave process(es) running in the background #3077.

Jako obejście problemu, możesz przełączyć się na pool: 'forks' lub pool: 'vmForks'.

vitest.config.js

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    pool: 'forks',
  },
});

CLI

vitest --pool=forks

Błędy segmentacji i błędy w kodzie natywnym

Uruchamianie natywnych modułów NodeJS w trybie pool: 'threads' może prowadzić do trudnych do zdiagnozowania błędów pochodzących z kodu natywnego. Przykładowe komunikaty błędów to:

• Segmentation fault (core dumped)
• thread '<unnamed>' panicked at 'assertion failed
• Abort trap: 6
• internal error: entered unreachable code

W takich przypadkach moduł natywny prawdopodobnie nie jest zbudowany w sposób bezpieczny dla wielu wątków. Jako obejście problemu, możesz przełączyć się na pool: 'forks', który uruchamia przypadki testowe w wielu procesach node:child_process zamiast w wielu wątkach node:worker_threads.

vitest.config.js

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    pool: 'forks',
  },
});

CLI

vitest --pool=forks