Comment fonctionne le stockage de session dans Playwright

Dans les tests d’automatisation, la connexion répétée à une application pour chaque scénario de test peut également prendre du temps et être inefficace. Pour résoudre ce problème, l’état du stockage de session apparaît avec le récit de «Les problèmes des temps modernes nécessitent une solution moderne»

En enregistrant l’état authentifié une fois et en le réutilisant dans plusieurs tests, l’ingénieur en automatisation peut ignorer les étapes de connexion redondantes et se concentrer uniquement sur les flux métier.

Dans cet article, nous approfondirons ce qu’est le stockage de session, son utilité dans le cadre d’automatisation, comment, où et quand vous implémentez le stockage de session, le dépannage des problèmes et leur solution, les meilleures pratiques pour sécuriser le stockage de session, ses avantages et ses inconvénients, et le code d’automatisation de test du monde réel pour stocker la session.

Voici les points que nous abordons dans cet article

• Qu’est-ce que le stockage de session ?
• Pourquoi réutiliser la session dans un cadre d’automatisation ?
• Comment fonctionne la convivialité des sessions dans Playwright ?
• Flux interne en coulisses
• Quand faut-il l’utiliser quand non ?
• Dépannage des problèmes courants
• Meilleures pratiques
• Avantages et inconvénients
• Configuration de la configuration globale pour le stockage de session dans Playwright

Qu’est-ce que le stockage de session ?

• Lorsque vous vous connectez à un site Web, vos informations de connexion (comme le jeton, les identifiants de session et les cookies) sont temporairement stockées dans le navigateur, appelé stockage de sessions.
• Cela aide le navigateur à se rappeler que vous êtes déjà connecté, de sorte que vous n’avez pas besoin de saisir à nouveau vos informations d’identification (nom d’utilisateur/e-mail et mot de passe) encore et encore lorsque vous traitez plusieurs scénarios de tests.
• Mais voici un problème : une fois que vous fermez le navigateur, ces données de session disparaissent

Pourquoi réutiliser la session dans Automation Framework ?

• Dans les tests d’automatisation, chaque scénario de test démarre en mode navigation privée, ce qui ouvre le nouveau navigateur à chaque fois, vous finirez par vous connecter encore et encore à chaque fois, ce qui n’est pas non plus efficace et rentable de faire les mêmes choses encore et encore.
• Pour surmonter le problème ci-dessus réutilisation des sessions entre en scène, ce qui nous aide à connectez-vous une fois et testez tout

Comment fonctionne la convivialité de la session dans Playwright ?

• Playwright stocke tous les cookies, données localStorage et sessionStorage du contexte de votre navigateur connecté dans un fichier (comme stockageState.json)
• Pendant l’exécution du test, Playwright lit ce fichier et restaure l’état du navigateur exactement tel qu’il était après la connexion.
• Cela signifie que l’application reconnaît l’utilisateur comme déjà connecté, aucun état de connexion et retarde la navigation directe de l’utilisateur vers la page d’accueil/tableau de bord. contourner l’état de connexion
• Pensez-y comme si vous preniez un instantané de votre navigateur connecté et réutilisiez l’instantané à chaque fois que vous effectuez un test.
  

  exemple de modèle d’état de stockage de session

Flux interne dans les coulisses

• Phase de configuration globale (avant le test)
  1. Lancements du navigateur
  2. La connexion s’effectue une seule fois
  3. Session enregistrée
  4. Navigateur fermé
• Phase d’exécution des tests
  • Chaque test récupère le fichier de session enregistré (stockageState.json) et commence à partir de l’état connecté en passant l’état de connexion
• Résultat
  • Testez l’atterrissage directement sur l’itinéraire protégé (comme /dashboard, home/, /profile, etc.) sans vous reconnecter
• Diagramme de flux

Flux de stockage de la session

Quand devriez-vous utiliser quand pas ?

• Faire quand
  • Tu as flux de connexion stable ça ne change pas fréquemment
  • Votre application Web utilise authentification basée sur une session ou un jeton (comme JWT)
  • Tu veux gagner du temps d’exécution et évitez les étapes de connexion répétitives
  • Vous travaillez avec grande combinaison d’essai (8+ fichiers de spécifications)
• Ne le fais pas quand
  • Vous testez la fonctionnalité de connexion elle-même (vous avez besoin d’une nouvelle session)
  • La session expire très rapidement (toutes les 2-3 minutes)

Dépannage des problèmes courants

Voici quelques problèmes auxquels les ingénieurs en automatisation sont généralement confrontés lors de la mise en œuvre de la réutilisabilité des sessions.

1. « Session non valide » ou « Utilisateur non connecté »

   • La session du magasin a peut-être expiré
   • Solution : réexécutez votre fichier de configuration globale pour générer un nouveau stockageState.json déposer

2. « Impossible de lire storageState.json »

   • Incompatibilité de chemin ou mauvaise structure de répertoires.
   • Solution : Utiliser chemin.resolve(__dirname, ‘storageState.json’) pour la gestion du chemin absolu

3. « Échec de la connexion dans les pipelines CI/CD »

   • .env les informations d’identification ne sont pas chargées correctement dans votre pipeline
   • Solution : assurez-vous de définir des variables d’environnement dans vos paramètres CI (comme GitHub, Gitlab, etc.).

Meilleures pratiques

• Gardez la logique de connexion séparée (comme vous l’avez fait dans votre Connexion.ts objet de page, qui maintient votre configuration maintenable
• Utiliser .env déposer pour les informations d’identification sensibles – jamais de données sensibles de code en dur
• Ignorer les fichiers de stockage dans Git
• Ignorer les fichiers .env dans Git

Avantages et inconvénients

• Pro

  • Exécution des tests plus rapide
  • Des tests plus stables
  • Moins d’entretien
  • Meilleure exécution parallèle
  • Rédaction de tests plus facile

• Inconvénients

  • Expiration de la session
  • Flux de connexion testé une seule fois
  • Configuration supplémentaire pour gérer le fichier de session

Configuration de la configuration globale pour le stockage de session dans Playwright

• Pour implémenter la réutilisabilité des sessions dans Playwright, nous devons d’abord créer un configuration globale déposer. Dans ce fichier, nous effectuons l’action de connexion une fois, récupérons le état de stockage de la session, puis stockez-le dans un fichier par exemple sessionStorage.json (vous pouvez le nommer selon vos préférences)
• Ensuite, nous configurons ceci fichier de configuration globale dans la configuration Playwright pour qu’il s’exécute avant tous les tests. Cela garantit que la session de connexion n’est créée qu’une seule fois.
• Puis, sous le utiliser bloc (ou dans la configuration spécifique du projet), nous référençons le même sessionStorage.json fichier afin que tous les tests ultérieurs puissent réutiliser l’état de session enregistré sans me reconnecter

Code

Structure du fichier d’installation globale

import {chromium, FullConfig} from "@playwright/test";
import path from 'path';
import { config as dotenv } from 'dotenv';
import { LOGIN } from './tests/Pages/Login';


dotenv(); // Load environment variables

async function globalSetup(config: FullConfig) {
// Launch browser
const browser = await chromium.launch({ headless: true });
const page = await browser.newPage();
const loginPage = new LOGIN(page);

// Get base URL from playwright config
const baseURL = config.projects[0].use?.baseURL as string;

// Fetch credentials from .env file
const email = process.env.ADMIN_EMAIL;
const password = process.env.ADMIN_PASS;

// Navigate to login page
await page.goto(`${baseURL}/admin/users/login/`);

// Perform login
await loginPage.performLoginWithValidCred(email, password)

// Wait until login completes (adjust URL as needed)
await page.waitForURL(`${baseURL}/admin/dashboard`);

// Save session state in a single file
const storageFile = path.resolve(__dirname, 'sessionStorage.json');
await page.context().storageState({ path: storageFile });
console.log(`Session saved to: ${storageFile}`);
 await browser.close();
}
export default globalSetup;

Structure du fichier de configuration

import { defineConfig, devices } from '@playwright/test';
import { config as dotenv } from 'dotenv';

dotenv();
export default defineConfig({
    testDir: './tests',
    fullyParallel: false,
    forbidOnly: !!process.env.CI,
    retries: process.env.CI ? 2 : 0,
    workers: process.env.CI ? 1 : undefined,
    reporter: 'html',
    timeout: 90000,

    // Run global setup once before all tests
    globalSetup: './global-setup.ts',
// Global use block with session storage
use: {
   baseURL: 'https://dev.example.com', // your base URL
   storageState: './sessionStorage.json', // single session file
   trace: 'on-first-retry',
   screenshot: 'only-on-failure',
},

 projects: [
{
  name: 'chromium',
  ...devices['Desktop Chrome']
   }],
});

Envelopper le tout

La réutilisation des sessions dans Playwright change la donne pour l’automatisation moderne des tests.
En enregistrant et en réutilisant l’état de connexion, nous :

• Réduisez les étapes répétitives
• Accélérer l’exécution
• Maintenir un code plus propre

Que vous exécutiez localement ou dans un pipeline CI/CD, cette approche garantit « Connectez-vous une fois, testez tout »

VOUS TROUVEZ CECI UTILE ? PARTAGEZ-LE