🔐 QA Session Cache Strategy

Démonstration de l'optimisation du temps d'exécution d'une suite Cypress via la mise en cache de session (cy.session()), en évitant de rejouer le flow de connexion complet à chaque test.

🎯 Pourquoi une mini-application auto-hébergée plutôt qu'un site public ?

Les premières versions de ce projet ciblaient des sites publics de démonstration (Sauce Demo, the-internet.herokuapp.com). Ces sites se sont révélés peu fiables pour ce cas d'usage précis : sessions invalidées côté serveur de façon imprévisible, comportement SPA empêchant la restauration directe d'état via URL, dynos gratuits qui redémarrent...

Plutôt que de masquer ces limites, le choix a été fait de construire une mini-application statique auto-hébergée (app/), basée sur localStorage, dont le comportement est entièrement prévisible et sous contrôle. Cela permet de démontrer proprement le pattern de cache de session sans dépendre de la fiabilité d'un tiers — une décision d'ingénierie assumée plutôt qu'un raccourci.

---

🧱 Stack technique

Domaine	Technologie
Framework de test	Cypress
Langage	TypeScript
Application cible	HTML/JS statique (auto-hébergée via http-server)
Orchestration serveur + tests	start-server-and-test
CI/CD	GitHub Actions

---

📂 Structure du projet

qa-session-cache-strategy/
├── app/                          # Mini-application statique (cible de test)
│   ├── index.html
│   ├── login.html
│   └── secure.html
├── cypress/
│   ├── e2e/
│   │   ├── without-session/      # Suite de référence : login à chaque test
│   │   └── with-session/         # Suite optimisée : session mise en cache
│   └── support/
│       └── commands.ts           # Commande login() avec cy.session()
├── .github/workflows/
│   └── compare-session-cache.yml
├── cypress.config.ts
└── package.json

---

🔑 La commande login() avec cache de session

Cypress.Commands.add("login", (username: string, password: string) => {
  cy.session(
    [username, password],
    () => {
      cy.visit("/login.html");
      cy.get("#username").type(username);
      cy.get("#password").type(password);
      cy.get("#login-button").click();
      cy.url().should("include", "secure.html");
    },
    {
      cacheAcrossSpecs: true,
      validate() {
        cy.window().then((win) => {
          expect(win.localStorage.getItem("authToken")).to.not.be.null;
        });
      },
    },
  );

  cy.visit("/secure.html");
});

Points clés :

• cacheAcrossSpecs: true : la session est partagée entre tous les fichiers de test de la suite.
• validate() : vérifie que le token d'authentification est toujours présent en localStorage avant réutilisation — cy.session() restaure automatiquement cookies, localStorage et sessionStorage, donc aucune manipulation manuelle n'est nécessaire.
• Résultat : un seul login réel est exécuté sur l'ensemble de la suite ; tous les tests suivants réutilisent directement la session en cache.

---

⚖️ Comparaison : avec vs sans cache de session

Le pipeline CI exécute les deux suites et publie la durée de chacune dans le résumé du run, pour comparer concrètement l'écart.

---

🚀 Exécution

npm install

# Suite de référence (login à chaque test)
npm run test:without-session

# Suite optimisée (cache de session)
npm run test:with-session

# Mode interactif (ouvre Cypress avec le serveur déjà lancé)
npm run cy:open

📸 Preuve d'exécution réelle

---

👤 Auteur

Mohamed Touaoua — QA Automaticien Ce projet fait partie de mon portfolio d'automatisation QA.