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>
30 lines
1.1 KiB
YAML
30 lines
1.1 KiB
YAML
# Postgres jetable pour la suite d'intégration SQL (`npm run test:integration`).
|
|
#
|
|
# Ne fait PAS partie du déploiement : ce fichier n'est utilisé qu'en local, à la
|
|
# demande. La suite rapide (`npm run check`) n'a jamais besoin de Docker.
|
|
#
|
|
# docker compose -f docker-compose.test.yml up -d
|
|
# npm run test:integration
|
|
# docker compose -f docker-compose.test.yml down -v
|
|
services:
|
|
postgres-test:
|
|
# Même famille d'image que la base de production : PostGIS est indispensable
|
|
# (colonnes geometry/geography, ST_MakeEnvelope, index GIST).
|
|
image: postgis/postgis:16-3.4
|
|
environment:
|
|
POSTGRES_USER: bm
|
|
POSTGRES_PASSWORD: bm
|
|
POSTGRES_DB: bm_test
|
|
ports:
|
|
- "55432:5432"
|
|
# Base entièrement en mémoire : elle est recréée à chaque exécution, la
|
|
# durabilité n'a aucun intérêt et coûte du temps.
|
|
tmpfs:
|
|
- /var/lib/postgresql/data
|
|
command: >
|
|
postgres -c fsync=off -c full_page_writes=off -c synchronous_commit=off
|
|
healthcheck:
|
|
test: ["CMD-SHELL", "pg_isready -U bm -d bm_test"]
|
|
interval: 2s
|
|
timeout: 3s
|
|
retries: 20
|