Commentaire : git diff origin/develop -- actions/authentication.test.js

Avant : L'ancien test utilisait fetch-mock — une bibliothèque externe pour simuler fetch (ajouté le 2019-03-15). La version es5/client était nécessaire pour la compatibilité avec les anciennes versions de Jest/CRA. [Code source develop]

Après : Supprimé. Trois raisons :

1. Vitest fournit vi.fn() directement — aucun paquet séparé n'est nécessaire.
2. fetch-mock version ^12.6.0 [package.json develop] possède une API incompatible avec les normes Fetch modernes et nécessite des polyfills [source fetch-mock sur GitHub].
3. Pas de dépendance fetch-mock restante — un paquet en moins, moins de vulnérabilités.

Avant : Bibliothèque pour la lecture/écriture de cookies dans le navigateur react-cookies@0.1.1 (ajouté le 2019-03-09, package.json develop [source sur GitHub]). Utilisée dans les anciens tests pour vérifier KEEP_SIGNED_IN (Ligne 94, Ligne 132, Ligne 183).

Pourquoi supprimé : Les cookies sont HTTP-only, JavaScript ne peut pas les lire (le test appelait cookies.loadAll(), qui appelle cookie.parse(document.cookie) — vrais cookies navigateur, pas de mock). fetch-mock place Set-Cookie dans les en-têtes de la Response, mais document.cookie n'est jamais peuplé. Ainsi, cookies.loadAll() renvoie toujours {} — vide. Le test passait non pas parce que la logique était correcte, mais parce que fetch-mock et react-cookies évoluent dans des univers séparés. react-cookies n'est plus dans les dépendances.

Après : API de mock de Vitest. Équivalent à jest.fn() [docs Jest], mais fourni directement par Vitest lui-même [vitest.dev] (version ^4.1.5 [package.json] ^⚡).

Méthodes principales utilisées :

• vi.fn() — crée une fonction mock (remplace global.fetch) — L49, L78, L95, L118, L143
• fn.mockResolvedValueOnce(value) — le prochain appel renvoie Promise.resolve(value) (chaîne de deux) — L50, L53
• fn.mockResolvedValue(value) — tous les appels renvoient Promise.resolve(value) — L79, L119, L144
• fn.mockRejectedValue(error) — l'appel lance une exception (erreur réseau) — L96
• vi.restoreAllMocks() — réinitialise tous les mocks entre les tests — L42, L110

Ce qui a changé : L'import de redux-thunk est passé de default (import thunk from) à named (import { thunk } from).

Dans redux-thunk version 3.x (^3.1.0 [source: export const thunk]), l'export par défaut a été supprimé — désormais l'export nommé { thunk } est requis.

configureMockStore([thunk]) — middleware permettant le dispatch de fonctions (thunks) au lieu de simples objets. Sans elle, store.dispatch(login(...)) ne fonctionne pas.

Retiré de l'import :

• loadSessionIfAvailable — ancien nom de la fonction de vérification de session. Dans authentication.js actuel, cette fonction n'existe plus — elle a été renommée en loadUserStatus (Ligne 30, renommé le 2019-03-18).
• logout — supprimé avec tout le bloc describe('logout'). La fonction logout n'existe pas dans authentication.js actuel [code source] (supprimé le 2019-07-13).
• USER_LOGOUT — type d'action pour la déconnexion. N'est pas exporté depuis authentication.js [seulement 3 types] (supprimé le 2019-07-13).
• userLogout — createur d'action pour la déconnexion. N'existe également plus [code source] (supprimé le 2019-07-13).

Ajouté à l'import :

• login — était déjà présent dans l'ancien test (Ligne 8), simplement restructuré
• loadUserStatus — nouveau nom pour loadSessionIfAvailable. La fonction réelle dans authentication.js:30.

mockStore déplacé au niveau du module — était créé 3× (dans login, logout, check session), maintenant créé une seule fois au début du fichier. [redux-mock-store]

Object.freeze() — [MDN]. L'ancien test gelait username et password (inutile — les primitives sont immuables). Dans le nouveau fichier, Object.freeze n'est utilisé que sur les objets d'état dans les tests du reducer, où c'est pertinent (protection contre les mutations dans une fonction pure).

afterEach(() => fetchMock.restore()) → beforeEach(() => vi.restoreAllMocks()) — remplacement de l'appel spécifique à fetch-mock par l'appel universel de Vitest vi.restoreAllMocks(). Passage de « après » à « avant » — garantit que les mocks ne fuient pas entre les tests.

Trois tests d'Action Creators, regroupés dans describe('action creators').

🔍 Erreur de frappe dans l'original : deux tests portant le même nom

it('should create an action to mark
    the login as success', () => {
  const expectedAction = {
    type: USER_LOGIN_SUCCESS
  };
  expect(userLoginSuccess())
    .toEqual(expectedAction);
});

it('should create an action to mark
    the login as success', () => {
  const expectedAction = {
    type: USER_LOGIN_FAILURE,
    payload: { error: 'Some uncool...' }
  };
  expect(userLoginFailure('Some...'))
    .toEqual(expectedAction);
});

Cela a traîné ainsi pendant 7 ans. Dans la version mise à jour, les noms ont été corrigés.

Que sont keepSignedIn / stayLoggedIn : La case à cocher « Rester connecté » dans le formulaire de connexion. Lorsqu'elle est activée, la chaîne suivante s'enclenche :

1. Frontend : login(username, password, keepSignedIn) (authentication.js:65) → corps POST : { stayLoggedIn: keepSignedIn } (Ligne 77)
2. Contrôleur : LoginPageRest.kt reçoit PostData<LoginData> (Ligne 96), champ stayLoggedIn dans LoginData.kt:34
3. Service : LoginService.authenticate() vérifie if (loginData.stayLoggedIn == true) (LoginService.kt:175), génère un jeton STAY_LOGGED_IN_KEY (UserTokenType.kt:31) et appelle addStayLoggedInCookie() (Lignes 177-178)
4. Cookie : CookieService définit le cookie avec le nom "stayLoggedIn" (CookieService.kt:201) et une durée de vie de 30 jours (Ligne 200)
5. Récupération : au prochain démarrage, si JSESSIONID a expiré, LoginService.checkStayLoggedIn() (LoginService.kt:250) lit le cookie via CookieService (CookieService.kt:65-75) — le serveur authentifie l'utilisateur sans mot de passe

L'ancien test tentait de le vérifier via cookies.loadAll() — mais le cookie n'arrive pas dans document.cookie dans le mock (voir Section 2).

Problèmes de l'ancien test :

1. fetchMock.mock(matcher, response) — API verbeuse : la fonction de correspondance analyse elle-même le corps de la requête et vérifie l'URL. [Ligne 62-80] [source fetch-mock]
2. headers: { 'Set-Cookie': '...' } — simule la définition d'un cookie de session, mais fetch-mock ne peut pas vraiment définir de cookies [Ligne 77]. Pourquoi : fetch-mock renvoie un objet Response avec des en-têtes — mais n'écrit pas dans document.cookie. react-cookies.loadAll() lit quant à lui exactement document.cookie = cookie.parse(document.cookie). La chaîne : fetch-mock → Set-Cookie dans l'en-tête → document.cookie reste vide → loadAll() renvoie {} → le test passe, mais vérifie le vide plutôt que le vrai comportement.
3. .catch({ throws: new Error('mock failed') }) — lancer une erreur si aucun matcher ne correspond. Un workaround qui masque les vrais problèmes [Ligne 80].
4. expectedActions = [BEGIN, SUCCESS] — INCORRECT. login() dispatch BEGIN, puis appelle loadUserStatus()(dispatch), qui dispatch un autre BEGIN puis SUCCESS. Au total, il doit y avoir 3 Actions, pas 2. [authentication.js:65-84] — login → loadUserStatus()(dispatch) à l'intérieur de .then().
5. cookies.loadAll() → toEqual({}) — teste la bibliothèque navigateur react-cookies, pas la logique de l'application [Ligne 94].

🏗 Analyse architecturale : pourquoi l'ancien test était voué à l'échec

Niveau d'abstraction incorrect. L'ancien test tentait de vérifier le comportement des cookies — mais les cookies sont gérés par le navigateur, pas par fetch() :

fetch-mock ──→  Response {
  headers: { 'Set-Cookie': 'JSESSIONID' }
}
      │
      │ Set-Cookie NON traité
      ▼
document.cookie = ""

react-cookies.loadAll() ──→  {}
expect(cookies.loadAll()).toEqual({})  ✓
Test réussi — a vérifié le vide, pas le comportement

fetch() ──→  HTTP Response {
  Set-Cookie: JSESSIONID=ABC
}
      │
      │ Le navigateur traite Set-Cookie
      ▼
document.cookie = "JSESSIONID=ABC"

react-cookies.loadAll() ──→  { JSESSIONID: "ABC" }
Cookie visible — comportement réel

Deux mondes de mock incompatibles. fetch-mock et react-cookies opèrent à des niveaux fondamentalement différents de la pile navigateur sans connexion dans l'environnement de test. fetch-mock remplace la couche HTTP (réseau), react-cookies lit la couche DOM (document.cookie). Dans un vrai navigateur, il y a un cookie jar entre les deux — un composant navigateur qui traite Set-Cookie depuis la réponse HTTP et l'écrit dans document.cookie. Dans jsdom avec fetch mocké, cette couche manque — le test vérifiait une illusion.

Le test a réussi par coïncidence. Le navigateur n'a pas traité Set-Cookie → document.cookie vide → cookies.loadAll() a renvoyé {}. Mais le test attendait {} ! Deux zéros se sont rencontrés — le vide a rencontré le vide — et ont engendré l'illusion d'un test fonctionnel.

Limite de responsabilité. Un test unitaire frontend doit vérifier quelles Actions Redux sont dispatchées en réponse à différentes réponses Fetch, pas comment le navigateur traite les en-têtes HTTP. Test correct : « fetch a renvoyé 200 → dispatch de [BEGIN, BEGIN, SUCCESS] ». Incorrect : « fetch a renvoyé Set-Cookie → vérifier si le cookie est arrivé dans document.cookie » — c'est un test navigateur, pas notre code.

Bug critique dans l'original :

if (url !== '/√/login' || options.method !== 'POST') — L'URL a été écrite avec le symbole racine carrée /√/login (U+221A), bien que l'URL correcte soit /rsPublic/login. [Ligne 103]

Ce test n'a jamais été exécuté — la requête POST /rsPublic/login ne correspondait pas à /√/login, tombant donc dans .catch({ throws: new Error('mock failed') }).

Le test pouvait néanmoins passer si l'erreur dans la chaîne .then().catch() était capturée — catchError dans authentication.js:84 dispatch FAILURE au lieu de relancer l'exception.

Problèmes :

1. fetchMock.mock('/rsPublic/login', 401) — ancienne API, simple URL et statut [Ligne 141]. Renvoyait { status: 401 } sans ok: false, mais handleHTTPErrors vérifie response.ok [rest.js:32].
2. payload: { error: 'Unauthorized' } — dans le vrai code, handleHTTPErrors lance Error('Fetch failed: Error 401') [rest.js:34]. Le test attend un message incorrect.

async/await — remplacement de .then() par async/await. Plus court, plus lisible, les erreurs ne sont pas avalies.

global.fetch = vi.fn().mockResolvedValueOnce() — deux appels fetch sont mockés séquentiellement :

1. Premier : réponse à POST /rsPublic/login — {} vide
2. Deuxième : réponse à GET /rs/userStatus (issu de loadUserStatus() dans login()) — avec userData, systemData, alertMessage

[BEGIN, BEGIN, SUCCESS] — CORRIGÉ. Trois Actions :