Vitest semble rapide en partie parce qu'il partage les mêmes hypothèses d'écosystème que Vite. Cela compte plus que des captures d'écran de benchmarks. Lorsque l'outil de construction et le lanceur de tests s'accordent sur l'ESM, la résolution de modules, les transformations et l'ergonomie de développement, l'ensemble du projet a moins de frictions dans la chaîne d'outils.
C'est pourquoi Vitest semble souvent être le choix par défaut naturel dans les projets frontend plus récents.
Pourquoi la transition se fait souvent en douceur
Dans les applications basées sur Vite, la configuration des tests peut rester légère :
import { defineConfig } from "vitest/config";
export default defineConfig({
test: {
environment: "jsdom",
globals: true,
},
});
L'attrait ne réside pas seulement dans la vitesse. C'est que l'application et les tests parlent le même langage de module.
Où Jest a encore du sens
Jest n'est pas obsolète. Il s'intègre encore bien lorsque :
- la base de code dépend déjà de son écosystème
- de grands mocks hérités sont construits autour de lui
- l'équipe possède des outils matures qu'il serait coûteux de remplacer
Le mauvais choix est de migrer parce que "plus récent signifie meilleur" sans vérifier les outils environnants et le style de test.
Règle préférable
Si le projet est d'abord Vite et ESM, Vitest est généralement le choix le plus propre. Si la base de code est déjà profondément investie dans les conventions Jest et que la configuration actuelle est stable, le cas de migration doit être plus fort que la mode.
Lectures complémentaires