Vitest fühlt sich schnell an, teilweise weil es die gleichen Ökosystemannahmen wie Vite teilt. Das ist wichtiger als Benchmark-Screenshots. Wenn das Build-Tool und der Test-Runner bei ESM, der Modulauflösung, Transformationen und der Benutzerfreundlichkeit während der Entwicklung übereinstimmen, hat das gesamte Projekt weniger Reibung in der Toolchain.
Das ist der Grund, warum Vitest oft wie die natürliche Wahl in neueren Frontend-Projekten erscheint.
Warum der Wechsel oft reibungslos verläuft
In Vite-basierten Anwendungen kann die Testkonfiguration klein bleiben:
import { defineConfig } from "vitest/config";
export default defineConfig({
test: {
environment: "jsdom",
globals: true,
},
});
Der Reiz besteht nicht nur in der Geschwindigkeit. Es liegt daran, dass die Anwendung und die Tests die gleiche Modulsprache sprechen.
Wo Jest weiterhin Sinn macht
Jest ist nicht obsolet. Es passt gut, wenn:
- der Codebestand bereits von seinem Ökosystem abhängt
- große Legacy-Mocks darum herum gebaut sind
- das Team über ausgereifte Werkzeuge verfügt, deren Austausch teuer wäre
Der falsche Schritt ist es, zu migrieren, weil "neu besser bedeutet", ohne die umliegenden Werkzeuge und den Teststil zu überprüfen.
Bessere Regel
Wenn das Projekt Vite-first und ESM-first ist, ist Vitest normalerweise die sauberere Wahl. Wenn der Codebestand bereits tief in Jest-Konventionen investiert ist und die aktuelle Konfiguration stabil ist, muss der Migrationsfall stärker sein als die Mode.
Weiterführende Literatur