Tests et build

Cette page couvre la vérification du frontend web (lint, types, tests unitaires), la construction de l'application et l'image Docker qui la sert. Les commandes s'exécutent depuis frontend-web/ après npm ci. La stratégie de test de l'ensemble du dépôt est dans Tests et qualité.

#Vérifications statiques

#Tests unitaires

Les tests utilisent Vitest 5 avec l'environnement jsdom, React Testing Library et les assertions de @testing-library/jest-dom. La configuration est dans vitest.config.mts :

export default defineConfig({
  plugins: [react()],
  resolve: { alias: { '@': path.resolve(__dirname, 'src') } },
  test: {
    environment: 'jsdom',
    globals: true,
    setupFiles: ['./vitest.setup.ts'],
    include: ['__tests__/**/*.test.{ts,tsx}'],
  },
});

vitest.setup.ts importe seulement @testing-library/jest-dom/vitest. Les fonctions describe, it, expect et vi sont globales.

npm test
npm run test:watch

#Ce qui est couvert

frontend-web/__tests__/lib.test.ts teste les fonctions pures de src/lib :

frontend-web/__tests__/components.test.tsx teste quatre composants, avec next/navigation simulé par vi.mock :

frontend-web/__tests__/consent.test.tsx teste le consentement à la mesure d'audience en 8 cas :

Les trois fichiers comptent 21 tests : 8 dans lib.test.ts, 5 dans components.test.tsx et 8 dans consent.test.tsx.

#Ce qui n'est pas couvert

Aucun test ne porte sur les pages, les hooks (useAuth, useBlockLuckyWallet, useSocket, useSound), les endpoints RTK Query ni la table des erreurs de transaction. Il n'y a pas de test de bout en bout (Playwright ou Cypress), ni de mesure de couverture. Les parcours sont vérifiés à la main contre un backend local, avec les comptes du seed (voir Comptes de démonstration et connexion). Les priorités raisonnables pour un repreneur sont getErrorMessage, notifyChainError et le parcours de connexion avec code.

#Build Next.js

npm run build
npm run start

npm run build produit .next/. Toutes les pages sont des composants client : les pages sans segment dynamique sont prérendues en HTML avec l'état initial (session non hydratée, thème clair, français), /invite/[code] et /boutique/[rewardId] sont rendues à la demande, puis le navigateur prend le relais et appelle l'API.

Les points d'attention :

La CSP n'est active qu'avec NODE_ENV=production, ce que fait next start. Pour vérifier les en-têtes en local, lancer npm run build puis npm run start et inspecter les réponses (voir Sécurité du navigateur).

#Image Docker

frontend-web/Dockerfile construit l'image en quatre étapes à partir de node:22-bookworm-slim (surchargeable par NODE_IMAGE) :

L'étape finale fixe NODE_ENV=production, PORT=3000 et HOSTNAME=0.0.0.0, expose le port 3000 et lance node server.js. Un HEALTHCHECK toutes les 15 secondes appelle http://127.0.0.1:3000/ avec fetch et considère le conteneur sain si le statut est inférieur à 500.

.dockerignore exclut node_modules, .next, out, coverage, les fichiers .env* (sauf .env.example), les journaux, .git, le Dockerfile et __tests__. Les tests ne sont donc pas exécutés dans l'image : ils le sont par la CI.

Construction manuelle, avec l'URL de l'API visée :

docker build -t blocklucky-web --build-arg NEXT_PUBLIC_API_URL=https://api.example.org/api --build-arg NEXT_PUBLIC_WS_URL=https://api.example.org frontend-web

Dans docker-compose.yml, le service web appartient au profil app, construit l'image avec http://localhost:2053/api et http://localhost:2053, publie le port 3000, monte /tmp et /app/.next/cache en tmpfs, reprend le bloc de durcissement commun et attend que le service backend soit sain. La stack complète est décrite dans Stack complète en conteneurs et les images dans Images Docker.

#Intégration continue

Le job « Frontend web (lint, typecheck, tests, build) » de .github/workflows/ci.yml ne s'exécute que si frontend-web/** ou le workflow a changé. Il enchaîne :

1. npm ci avec la version de Node.js de .nvmrc ;
2. npm audit --omit=dev --audit-level=high ;
3. npm run lint, npm run typecheck, npm test ;
4. restauration du cache .next/cache, puis npm run build ;
5. recherche de secrets et de source maps dans .next/static.

L'image est construite à part, sans être poussée, dans le job des images, puis analysée par Trivy. Le détail des jobs est dans Intégration continue.

#Avant de livrer une modification

npm run lint
npm run typecheck
npm test
npm run build

Ces quatre commandes reproduisent la CI. Si la modification touche les en-têtes ou l'URL de l'API, ajouter un npm run start et vérifier dans le navigateur que la CSP ne bloque aucun appel.