Tests et qualité

Chaque projet du monorepo a ses propres commandes de vérification. La CI (.github/workflows/ci.yml) les rejoue sur chaque pull request, en ne lançant que les jobs des projets modifiés. Cette page donne, projet par projet, ce qu'il faut lancer avant de pousser et ce que la CI exige pour qu'une pull request soit fusionnable.

#Avant d'ouvrir une pull request

Une commande par projet modifié, les mêmes que dans CONTRIBUTING.md. Elles rejouent en local l'essentiel des contrôles de la CI.

cd backend && npm run typecheck && npm run lint && npm run env:check && npm test

cd frontend-web && npm run lint && npm run typecheck && npm test

cd mobile-app && npm run typecheck && npm run lint

cd smart-contract && npm run lint && npm run test:coverage && npm run coverage:check

cd documentation-officielle && npm run check

Pour l'Office de Tourisme, depuis frontend-office-tourisme/ :

node ../.github/scripts/check-static-links.mjs .

#Vue d'ensemble de la CI

flowchart LR
    CH["changes : dossiers modifiés"] --> BE["backend"]
    CH --> SC["contracts"]
    CH --> WE["web"]
    CH --> MO["mobile"]
    CH --> TO["tourisme"]
    SC --> CI["chain : backend sur un vrai nœud"]
    BE --> CI
    BE --> DO["docker : images, Compose, Trivy"]
    SC --> DO
    WE --> DO
    TO --> DO
    GL["secrets : gitleaks"]
    DOC["documentation"]

Une modification de .github/workflows/ci.yml déclenche tous les jobs. Le job contracts tourne aussi quand seul le backend change, parce que le backend embarque les ABI des contrats. Toutes les actions GitHub sont épinglées par empreinte de commit (actions/checkout@11d5960a...) et non par étiquette, ce qui empêche une étiquette déplacée d'injecter du code dans la CI.

La liste générée des jobs est dans Intégration continue.

#Smart contracts

Les tests sont décrits dans Tests, fuzzing et couverture.

#Backend

#Tests unitaires et d'API

Les tests de backend/__tests__/ appellent l'application Express avec Supertest. Prisma et Redis y sont remplacés par des doublures en mémoire (prisma.mock.ts, redis.mock.ts) ; setup-env.ts force BLOCKCHAIN_MODE=simulated et désactive le code de connexion par email, la double authentification des administrateurs et la vérification d'âge (AGE_VERIFICATION_REQUIRED=false). Les tests du refus 403 des comptes non vérifiés, dans lottery.test.ts et marketplace.test.ts, réactivent le contrôle en modifiant env.AGE_VERIFICATION_REQUIRED le temps du test ; identity.test.ts couvre l'envoi des pièces et la décision de la Mairie. Ces tests n'ont donc besoin ni de base, ni de Redis, ni de blockchain.

#Tests sur une vraie blockchain

Le job chain construit l'image de smart-contract/, qui démarre un nœud Hardhat, déploie les contrats et lance un oracle VRF local, puis exécute npm run test:chain avec PostgreSQL et Redis réels. Le scénario de onchain-lottery.chain.ts couvre l'achat, le cadeau, l'avance du temps (evm_increaseTime), le tirage par le keeper, le versement de la cagnotte, le POAP et le disjoncteur. En local :

docker compose up -d --wait
cd backend && npm run test:chain

Voir Tests sur une vraie chaîne.

#Frontend web

Voir Tests et build.

#Application mobile

#Office de Tourisme

Il n'y a pas de test fonctionnel : les parcours (filtres, panier, commande) se vérifient à la main. Voir Servir et déployer.

#Documentation

npm run check, depuis documentation-officielle/, construit le site dans un dossier temporaire, le compare à site/, vérifie les liens, les ancres et les descriptions des tableaux générés. Le job tourne sur chaque pull request, même sans modification de la documentation, parce qu'un changement du code peut rendre une page générée obsolète. Voir Écrire la documentation.

#Contrôles transverses

La liste blanche de gitleaks ne contient que deux valeurs publiques de développement, refusées par le backend en production : la clé ENCRYPTION_KEY de démonstration et la clé privée du compte Hardhat n° 0. L'image de la blockchain locale n'est pas analysée par Trivy : elle sert au développement et à la CI, jamais en production.

#Tests de charge

Les scénarios k6 de load-tests/ ne sont pas lancés par la CI. Ils servent avant un événement à fort trafic (ouverture des ventes, tirage public) :

docker run --rm -i -e BASE_URL=http://host.docker.internal:2053 grafana/k6 run - < load-tests/smoke.js

Voir Tests de charge.

#Quand la CI échoue