Nicolas Fryder
7b53d47d71
1. Suite d'intégration SQL (npm run test:integration:full) Ferme le dernier angle mort : la SÉMANTIQUE du SQL. Le parseur de grammaire ne voyait pas un nom de colonne inexistant, un type incompatible ou une fonction PostGIS mal appelée — soit exactement la classe de bugs qui n'apparaissait qu'en production. Technique : chaque requête émise par l'application passe par `PREPARE`. Postgres l'analyse et la planifie entièrement — colonnes, types, opérateurs jsonb, fonctions PostGIS — SANS l'exécuter ni nécessiter de données. Rapide, et ça couvre aussi les requêtes que le parseur JS ne sait pas lire : jsonb_build_object, `jsonb - text[]`, `raw ? 'clé'`, make_interval, l'opérateur spatial && et l'agrégation en grille des clusters. Les migrations réelles sont appliquées dans l'ordre réel : une migration invalide échoue ici, plus au redémarrage du conteneur en production. 54 tests. Exige Docker, donc HORS de `check` et du hook pre-push — la boucle de développement reste à 6 s. Base jetable en tmpfs (fsync off). Deux témoins vérifient que le détecteur n'est pas inopérant : une colonne inexistante et un type incompatible doivent être rejetés. 2. Les boutons de crawl ne mentent plus La production ne déploie pas le service crawler (docker-compose.yml ne le contient pas). Les boutons « Crawl incrémental », « Enrichir » et « Crawl complet » y créaient des demandes que personne ne consommait, avec un libellé promettant une exécution « sous ~1 min ». Ils s'appuient désormais sur le battement de cœur : pas de crawler vivant, boutons désactivés et raison affichée. « Alimenter le géocodage » reste actif, puisqu'il est traité par le geocoder. Je n'ai PAS ajouté le crawler au compose de production : ce serait déclencher du crawl depuis la prod, décision qui n'est pas la mienne. Régression évitée au passage : re-rendre le bloc de traitements effaçait le message de retour (« Demande #77 enregistrée »), puisque loadPilotage() est rappelé après un clic réussi. L'état des boutons est donc mis à jour sans reconstruire le DOM. Détecté par un test existant. Correctif : la suite d'intégration était happée par le glob de vitest.config.js et allongeait `check` de 6 à 22 s en exigeant Docker. Tests : 580 JS + 54 intégration, 63 Python, 89 Playwright Co-Authored-By: Claude <noreply@anthropic.com>
48 lines
2 KiB
JavaScript
48 lines
2 KiB
JavaScript
import { defineConfig } from "vitest/config";
|
|
|
|
/**
|
|
* Environnement `node` par défaut (démarrage quasi instantané). Les rares
|
|
* fichiers qui ont besoin du DOM déclarent leur propre environnement via un
|
|
* docblock en tête de fichier :
|
|
*
|
|
* // @vitest-environment jsdom
|
|
*
|
|
* Aucun test ne démarre de conteneur ni de vraie base : les routes API sont
|
|
* testées via `fastify.inject()` avec un faux pool (test/helpers/fakePool.js),
|
|
* et les tests a11y parsent le HTML statique avec jsdom + axe-core.
|
|
*/
|
|
export default defineConfig({
|
|
test: {
|
|
environment: "node",
|
|
// Pool laissé au défaut (forks) : mesuré contre les alternatives sur cette
|
|
// suite, 401 tests —
|
|
// forks (défaut) : 3,5 s
|
|
// threads, isolate: true : lent
|
|
// threads, isolate: false : 18,8 s (mise en place de jsdom pénalisée)
|
|
// L'intuition « threads sans isolation = plus rapide » est fausse ici.
|
|
// Re-mesurer avant de changer.
|
|
include: ["apps/*/test/**/*.test.js"],
|
|
// La suite d'intégration exige Docker : elle a sa propre config
|
|
// (vitest.integration.config.js) et ne doit jamais entrer dans `check`.
|
|
exclude: ["**/node_modules/**", "apps/api/test/integration/**"],
|
|
reporters: ["default"],
|
|
coverage: {
|
|
provider: "v8",
|
|
reporter: ["text", "lcov"],
|
|
include: ["apps/api/src/**/*.js"],
|
|
// migrate.js s'exécute au démarrage du conteneur et appelle process.exit :
|
|
// le couvrir demanderait une vraie base, ce qu'on s'interdit ici.
|
|
// server.js n'est qu'un point d'entrée (5 lignes), la logique est dans app.js.
|
|
exclude: ["apps/api/src/migrate.js", "apps/api/src/server.js"],
|
|
// Seuils = cliquet anti-régression. Ils ne prouvent PAS que les tests
|
|
// vérifient quelque chose (seule la mutation le fait, cf. `npm run
|
|
// test:mutation`), mais ils empêchent d'ajouter du code non exécuté.
|
|
thresholds: {
|
|
statements: 85,
|
|
branches: 80,
|
|
functions: 85,
|
|
lines: 85,
|
|
},
|
|
},
|
|
},
|
|
});
|