Nicolas Fryder
366bb8630d
Passe de performance guidée par la mesure, pas par l'intuition. Porte de qualité (`npm run check`) — la commande qui tourne des dizaines de fois par jour : - Les 5 vérifications sont indépendantes : exécutées en parallèle via scripts/check.mjs au lieu d'un enchaînement `&&` qui imposait la somme des durées ET 7 démarrages npm imbriqués. 14 s → 6 s - Cache ESLint (--cache) et compilation incrémentale tsc. 16 s → 14 s - Chemin critique restant : vitest 4,9 s, dont ~2 s de mise en place jsdom. Tests de mutation : - Config Vitest dédiée en pool `threads` sans ré-isolation. Mesuré sur le dry-run Stryker : overhead d'amorçage 12 844 ms → 1 592 ms, soit ~90 % du cycle par mutant. 5 min 02 → 3 min 40 - Le mode incrémental ramène le profil complet à 12 s après une édition. Pistes mesurées puis REJETÉES (documentées dans README-CI.md pour éviter qu'on les retente) : - Découper la mutation en 5 processus Stryker parallèles : 262 s contre 235 s. Chaque processus repaie son bac à sable et son dry-run. - Monter `concurrency` de 6 à 16 : aucun effet (~8,5 mutants/s partout), le débit est borné par l'orchestration mono-processus de Stryker. - Séparer vitest API/frontend en deux processus : aucun gain, jsdom domine. - Pool `threads` sur la suite complète : 18,8 s contre 3,5 s. Le bon réglage dépend du jeu de fichiers (jsdom ou non) — d'où deux configs distinctes. Le périmètre muté est inchangé (1511 mutants) : un score obtenu en retirant les mutants gênants vaudrait moins que pas de score. Corrections au passage : - scripts/*.mjs n'était couvert par aucune section ESLint - Les deux suites pytest ont chacune un paquet `src` : réunies dans un seul processus, le premier importé masquait l'autre. Séparées (et parallèles). Co-Authored-By: Claude <noreply@anthropic.com>
30 lines
1.2 KiB
JavaScript
30 lines
1.2 KiB
JavaScript
import { defineConfig } from "vitest/config";
|
|
|
|
/**
|
|
* Configuration Vitest dédiée aux tests de mutation.
|
|
*
|
|
* Stryker recharge l'ensemble des fichiers de test à chaque activation de
|
|
* mutant. Avec les 11 fichiers de la suite complète, cet amorçage représentait
|
|
* l'essentiel du temps d'exécution (~270 ms par mutant, alors qu'un test met
|
|
* ~8 ms). On ne déclare donc ici que les fichiers qui couvrent réellement les
|
|
* modules mutés — les autres ne feraient qu'être chargés puis ignorés.
|
|
*
|
|
* À tenir synchronisé avec le champ `mutate` de stryker.config.json.
|
|
*/
|
|
export default defineConfig({
|
|
test: {
|
|
environment: "node",
|
|
// Voir vitest.mutation.full.config.js pour les mesures : sur un jeu de
|
|
// fichiers 100 % node, threads sans ré-isolation divise l'overhead
|
|
// d'amorçage par 8. Ne pas reporter tel quel dans vitest.config.js, qui
|
|
// contient le test a11y sous jsdom (où ce réglage est plus lent).
|
|
pool: "threads",
|
|
poolOptions: { threads: { isolate: false, singleThread: true } },
|
|
fileParallelism: false,
|
|
include: [
|
|
"apps/api/test/validate.test.js",
|
|
"apps/api/test/adminAuth.test.js",
|
|
],
|
|
reporters: ["default"],
|
|
},
|
|
});
|