Tests

Le backend a deux niveaux de tests automatisés. La suite principale, lancée par npm test, exerce l'application Express de bout en bout avec Supertest, en mode BLOCKCHAIN_MODE=simulated, sur des doublures en mémoire de Prisma et de Redis : elle ne demande ni base, ni Redis, ni nœud. La suite de chaîne, lancée par npm run test:chain, rejoue le parcours complet sur une vraie base PostgreSQL, un vrai Redis et un nœud Hardhat avec les contrats déployés. La stratégie de test de l'ensemble du dépôt est décrite dans Tests et qualité.

#Commandes

Depuis backend/ :

La configuration principale est dans la section jest de backend/package.json : préréglage ts-jest, environnement node, dossier dist/ ignoré et fichier de préparation __tests__/setup-env.ts. Elle ne fixe aucun seuil de couverture.

#Résultats actuels

Exécution de npx jest sur la branche de travail, le 12 novembre 2026 :

Test Suites: 19 passed, 19 total
Tests:       108 passed, 108 total
Snapshots:   0 total
Time:        63.977 s

Avec npm run test:coverage, mesure du 11 novembre 2026, sur l'ensemble des fichiers chargés par les suites :

Le chemin onchain des services (passerelle, indexeur réel, keeper, file d'actions, portefeuilles) n'est pas exécuté par cette suite, ce qui explique l'essentiel des branches non couvertes. Il est couvert par la suite de chaîne.

#Préparation de l'environnement

backend/__tests__/setup-env.ts s'exécute avant chaque suite et fixe :

process.env.LOGIN_EMAIL_CODE_REQUIRED = 'false';
process.env.ADMIN_MFA_REQUIRED = 'false';
process.env.BLOCKCHAIN_MODE = 'simulated';
process.env.AGE_VERIFICATION_REQUIRED = 'false';

Jest définit NODE_ENV=test, ce qui coupe la création du client Redis, l'envoi SMTP, le dépôt S3, les logs et les métriques par défaut, et relève les limites de débit à 10 000 requêtes. Les suites qui testent le code email, la 2FA obligatoire des administrateurs ou la vérification d'âge modifient env.LOGIN_EMAIL_CODE_REQUIRED, env.ADMIN_MFA_REQUIRED ou env.AGE_VERIFICATION_REQUIRED au début du test ou de la suite et les restaurent à la fin. La vérification d'âge n'est réactivée que dans des blocs de lottery.test.ts et marketplace.test.ts.

#Doublures de Prisma et Redis

Chaque suite remplace les deux modules de configuration avant d'importer l'application :

jest.mock('../../src/config/prisma.config', () => ({
  __esModule: true,
  prisma: prismaMock,
  default: prismaMock,
}));

jest.mock('../../src/config/redis.config', () => ({
  __esModule: true,
  redis: redisMock,
  default: redisMock,
}));

import app from '../../src/app';

Ces doublures ont des limites à garder en tête en écrivant un test :

Une nouvelle requête Prisma dans le code doit être ajoutée à la doublure, sinon le test échoue sur une fonction absente.

#Suites

Plusieurs suites (admin, admin-accounts, auth-security, partners, full-draw-flow) signent directement leurs jetons avec sessionService.sign(...) après insertion du compte dans la doublure ; les autres passent par POST /auth/login, qui délivre le jeton immédiatement puisque le code email est désactivé.

#Test sur une vraie chaîne

backend/__tests__/chain/onchain-lottery.chain.ts contient deux tests, avec un délai de 120 secondes par test (backend/jest.chain.config.json). Sa préparation setup-chain-env.ts force BLOCKCHAIN_MODE=onchain, NODE_ENV=development, les adresses des contrats locaux, désactive le code email, la 2FA obligatoire et la vérification d'âge, et met DRAW_REVEAL_DELAY_SECONDS à 0 s'il n'est pas défini.

1. Achat, cadeau, tirage et versement. Deux citoyens se connectent ; leur portefeuille intégré est différent de l'adresse envoyée et a reçu la dotation. Le statut est en phase OPEN sans revealAt. Alice achète son ticket, dont le numéro a 5 chiffres, puis un second achat est refusé en 409 PlayerLimitReached. Bob achète le sien, en offre un à Dave, puis se voit refuser un cadeau à Alice, qui a déjà son ticket. Le test avance le temps du nœud (evm_increaseTime, evm_mine) au-delà de la fin du tour, appelle runKeeperOnce() qui demande le tirage, attend que l'indexeur enregistre le gagnant, vérifie que la cagnotte vaut 90 % des 3 tickets et que l'historique donne le numéro gagnant et isWinner, attend le versement par le worker chain-actions puis la frappe des POAP visibles dans my-tickets.
2. Disjoncteur. Un administrateur met le contrat en pause par POST /api/v1/admin/circuit-breaker ; paused() vaut true sur la chaîne ; un achat renvoie 503 avec circuitBreaker: true ; la reprise remet paused() à false.

Prérequis : PostgreSQL et Redis joignables, nœud Hardhat lancé avec les contrats et l'oracle VRF local (conteneur blockchain de docker-compose.yml), base migrée et vierge, cohérente avec l'état de la chaîne. Le test crée ses comptes avec un suffixe unique et suppose un tour ouvert sur la chaîne.

docker compose up -d --wait
cd backend
npx prisma migrate deploy
npm run test:chain

#Intégration continue

Le workflow .github/workflows/ci.yml exécute les deux suites dans des jobs séparés.

La couverture du backend n'est pas mesurée en CI. Le détail des jobs est dans Intégration continue.

#Écrire un test

1. Créer __tests__/<dossier>/<sujet>.test.ts.
2. Déclarer les deux jest.mock avant import app from '../../src/app'.
3. Appeler resetPrismaMockStore() et resetRedisMockStore() dans beforeEach.
4. Insérer les données nécessaires par les fonctions de la doublure (prismaMock.user.create(...)) et signer un jeton avec sessionService.sign.
5. Appeler l'API avec request(app) et vérifier statut, success, data ou errors.
6. Pour un email, espionner emailService.sendTemplateEmail avec jest.spyOn et lire les variables reçues.

Le guide Ajouter un endpoint contient un exemple complet.