Tests (front et back)

Chaque ticket suit ce cycle : ticket Jira → branche Git → Pull Request → Lint + Tests → Docs à jour → Done.

Ce dépôt distingue tests unitaires (comportement isolé, mocks) et tests fonctionnels (chaîne complète : HTTP côté API, navigateur côté front).

Couche	Unitaire	Fonctionnel
Front	Vitest + jsdom	Playwright (navigateur réel)
Back	Jest (Node)	Jest + Supertest (HTTP sur l’app Nest)

Les détails d’auth et de base pour le back sont dans docs/dev/back/auth.md et docs/dev/back/database.md.

Conditions réelles (hors mocks)

• Playwright (mode auth réelle) : le navigateur enchaîne le portail AUTH, le callback BDD et l’API BDD. Il faut donc que le back soit démarré et joignable avec la même BASE_URL que côté front (souvent http://localhost:3000). Le front est en principe lancé par Playwright via webServer (yarn dev dans playwright.config.js).

• E2E API back (yarn test:e2e) : Nest est monté dans le processus Jest ; un second terminal avec yarn start n’est en général pas nécessaire. Les cas d’auth BDD utilisent maintenant des app_access_token signés localement, sans login réel via le portail AUTH.

---

Front

Tests unitaires (Vitest)

• Où : sous front/src/__tests__/, en miroir de la structure de src/ (composants, pages, stores, router, etc.).

• Convention : fichiers *.spec.js.

• Commande : depuis front/ :

  yarn test

• Config : front/vitest.config.js (fusion avec la config Vite, environnement jsdom). Le dossier front/e2e/ est exclu des tests unitaires pour ne pas mélanger avec Playwright.

Les tests ciblent des unités fines (composants Vue, Pinia, garde de routes) sans lancer le serveur de dev.

Couverture unitaire utile actuelle autour de l auth :

• AuthCallbackPage.spec.js
  • callback avec acces refuse
  • restauration locale via app_access_token
• App.spec.js
  • protection des routes non publiques
  • redirection si le jeton applicatif manque
• stores/auth-store.spec.js
  • validation locale du app_access_token
  • logout local et invalidation de cache

Tests fonctionnels (Playwright)

• Où : front/e2e/, fichiers *.spec.js.

• Commande : depuis front/ :

  yarn test:e2e

  Variantes utiles en local : yarn test:e2e:ui, yarn test:e2e:headed. Première installation des navigateurs : yarn test:e2e:install.

• Comportement : playwright.config.js démarre yarn dev (sauf si une instance tourne déjà en local non-CI) et utilise FRONT_URL comme baseURL (voir front/.env.example). En CI, reuseExistingServer est désactivé : prévoir un port libre et la même URL que celle attendue par la config.

• Auth réelle (optionnel) : certains scénarios ne s’exécutent que si E2E_REAL_AUTH est activé (1, true ou yes) et que E2E_TEST_USER_EMAIL / E2E_TEST_USER_PASSWORD sont renseignés. Les variables sont chargées depuis la racine front/ (fichier .env + pas de dépendance au cwd des workers Playwright). Sans cette configuration, les tests concernés sont ignorés (skip).

Parcours suivis et backlog Playwright :

• Voir docs/dev/front/playwright.md
• Les specs actuelles couvrent : smoke public, login, mot de passe oublié, upload, gestion d acces au callback, dossiers admin (BDD-21) et pagination des fichiers d un dossier admin (BDD-37).
• Les prochains cas prioritaires à garder verts sont :
  • préservation de redirect après login
  • gestion d un 401 pendant l hydratation utilisateur
  • logout automatique sur session invalide en navigation protégée
  • non-régression du dépôt après authentification réelle
  • consultation des fichiers déposés après connexion
  • rafraîchissement de la liste après un upload réussi
  • téléchargement d'un fichier déposé avec conservation du nom original
  • copie d'un lien sécurisé vers un fichier déposé
  • pagination de /admin/folders avec filtres et recherche
  • création d un dossier depuis une entreprise éligible (/folders/enterprises, hasFolder)
  • flux réel AUTH -> BDD avec app_access_token
• Les specs admin nécessitent E2E_TEST_ADMIN_EMAIL / E2E_TEST_ADMIN_PASSWORD en plus des variables client.

---

Back

Tests unitaires (Jest)

• Où : à côté du code dans back/src/, fichiers *.spec.ts (ex. user.service.spec.ts à côté de user.service.ts).

• Commande : depuis back/ :

  yarn test

  Variantes : yarn test:watch, yarn test:cov.

• Config : section jest de back/package.json (rootDir: src, testRegex: .*\.spec\.ts$, alias src/*).

Ces tests mockent les dépendances (Prisma, HTTP externe) pour valider la logique des services, guards, handlers d’exceptions, etc.

Couverture utile actuelle autour de l auth :

• authGuard.spec.ts
  • X-App-Access-Token absent
  • jeton applicatif invalide
  • jeton applicatif ne ciblant pas bdd
  • chargement du profil local et du role

Tests fonctionnels / E2E API (Jest + Supertest)

• Où : back/test/e2e/, fichiers *.e2e-spec.ts (ex. app-controller.e2e-spec.ts, users-controller.e2e-spec.ts).

• Commande : depuis back/ :

  yarn test:e2e

• Config : back/test/jest-e2e.json (roots sur test/e2e, résolution src/* vers back/src).

Ces tests montent l’application Nest et envoient de vraies requêtes HTTP. Ils vérifient le contrat des endpoints (statuts, corps) sans navigateur.

• Auth BDD : les specs E2E backend BDD signent un app_access_token de test avec APP_ACCESS_TOKEN_SECRET. Il suffit donc d’avoir une config backend cohérente (APP_ACCESS_TOKEN_SECRET, APPLICATION, ENVIRONMENT, base tool accessible).

---

Récapitulatif des commandes

Contexte	Type	Commande (répertoire)
Front	Unitaire	front/ → yarn test
Front	Fonctionnel	front/ → yarn test:e2e
Back	Unitaire	back/ → yarn test
Back	E2E API	back/ → yarn test:e2e

---

Bonnes pratiques (équipe)

• Garder les tests unitaires rapides et déterministes ; isoler le réseau et la base avec des mocks.
• Réserver les tests fonctionnels aux parcours critiques (routes protégées, login, endpoints d’intégration) pour limiter le temps d’exécution et la fragilité (ports, services externes).
• Pour l’auth réelle en local ou CI, documenter les secrets dans .env.example sans valeur sensible ; ne jamais committer de mots de passe.

Liens utiles

• docs/dev/front/playwright.md
• docs/dev/back/auth.md
• docs/dev/back/console-admin-sync.md