Réutilisez l'état de connexion. Ne publiez pas le secret.

Une suite de versions se connecte avant chaque petite vérification. La majeure partie du parcours est consacrée à l'attente du même formulaire de connexion. L'enregistrement de l'état du navigateur authentifié peut supprimer cette répétition, mais le fichier enregistré ne constitue pas des données de test inoffensives. Il peut contenir suffisamment d'informations pour servir de compte de test.

Ce guide suit la documentation d'authentification de Playwright pour rendre la limite explicite. La capture d'écran ci-jointe est un écran de faux compte local. Aucun véritable identifiant, jeton ou enregistrement client n'a été utilisé. La question est de savoir comment préparer un état réutilisable en toute sécurité, et non comment contourner la politique d'authentification d'une application.

Décidez ce que la suite est autorisée à réutiliser

Un test d'un paramètre de profil nécessite généralement une session authentifiée. Il n'est pas nécessairement nécessaire d'exercer à nouveau le formulaire de connexion. Un test de connexion lui-même a une tâche différente : vérifier le flux d'authentification réel, le comportement de rejet et les règles de session pertinentes. La réutilisation de l'état dans le premier groupe ne doit pas effacer silencieusement le deuxième groupe.

Notez ces groupes avant d'ajouter un raccourci. Un projet d'installation peut effectuer l'état de connexion et de sauvegarde approuvé ; les tests dépendants peuvent démarrer à partir de cet état. Le guide d'authentification montre ce modèle. L'État doit appartenir à une identité de test contrôlée dans un environnement approuvé, avec uniquement les privilèges dont le test a besoin.

// After your approved test-account login has completed:
await expect(page.getByRole('button', { name: 'Sign out' })).toBeVisible();
await page.context().storageState({ path: 'playwright/.auth/user.json' });

Le bouton visible est le contrat de préparation de notre application illustrative, et non une preuve universelle que chaque méthode d'authentification est terminée. Votre application peut nécessiter une condition stable différente. Attendez que la session soit établie avant de la sauvegarder, sinon le prochain test pourrait recevoir un état incomplet et produire un échec déroutant.

Le fichier appartient en dehors du référentiel

Playwright avertit que l'état enregistré du navigateur peut inclure des cookies sensibles et des en-têtes utilisables pour usurper l'identité d'un compte. Sa documentation décourage de confier ces fichiers à des référentiels privés ou publics. Un référentiel privé reste un canal de distribution et non un magasin d'informations d'identification sécurisé.

playwright/.auth/

Ignorer le répertoire est une mesure de prévention et non de correction. Si un fichier d'état a déjà été validé, sa suppression de l'arborescence de travail n'efface pas les révisions antérieures. Arrêtez de distribuer cet artefact et suivez le processus d'exposition des informations d'identification de votre organisation. Ne placez pas de fichier d'état réel dans un didacticiel, une pièce jointe à un problème, un ensemble de traces ou une capture d'écran pour rendre une explication plus concrète.

Passez en revue les règles de téléchargement d'artefacts ainsi que les règles de contrôle de source. Une tâche CI peut télécharger l'intégralité de l'espace de travail après un échec. Un fichier ignoré peut toujours entrer dans cette archive. Conservez explicitement l'état de connexion enregistré hors des ensembles de débogage et des sauvegardes qui n'en ont pas besoin. Utilisez des comptes de test et un accès de courte durée là où votre environnement les prend en charge.

La réutilisation n'est pas une promesse à vie

L'état stocké expire. Le guide recommande de supprimer l'état expiré et note que les répertoires de sortie du projet sont nettoyés avant l'exécution. Choisissez un cycle de vie qui correspond à la stratégie de session plutôt que de supposer que le fichier d'hier est valide pour toujours. Un échec de configuration devrait arrêter les vérifications dépendantes pour une raison utile, et non se transformer en dizaines d'échecs de page sans rapport.

Les mécanismes de stockage sont également importants. Le guide d'authentification de Playwright traite des cookies, du stockage local et d'autres mécanismes, avec une gestion spéciale pour le stockage de session. Ne présumez pas que chaque implémentation de connexion est capturée par l'appel storageState le plus simple. Vérifiez ce que votre application utilise et vérifiez qu'un nouveau contexte peut atteindre la page authentifiée prévue.

Une expérience locale sûre utilise un faux état pour démontrer le mécanisme. Cela prouve que le navigateur peut restaurer cette valeur sélectionnée, et non qu'un fournisseur d'identité, une politique MFA ou une session de production a été validé. Gardez cette distinction dans le rapport de test.

Donner aux tests parallèles un état suffisamment indépendant

La réutilisation d'un compte peut être raisonnable pour les tests en lecture seule qui ne modifient pas l'état du serveur partagé. Cela devient risqué lorsque plusieurs tests éditent les mêmes préférences ou enregistrements. La séparation du contexte du navigateur ne sépare pas le compte du serveur. Notre précédent guide d'isolement couvre cette collision ; ici, la règle pratique consiste à faire correspondre la configuration de l'authentification au modèle de mutation de la suite.

Conservez le contrôle de préparation, la portée de l'identité, le mécanisme de stockage, la règle d'expiration et les exclusions d'artefacts dans une petite note de configuration. Cette note facilite la révision d'un test généré. Un réviseur peut voir pourquoi la connexion est réutilisée, quels tests de connexion sont toujours en cours et où l'état est autorisé à aller.

AnyTest décrit les agents explorant une application et créant des tests de bout en bout pour un examen humain. Appliquez les mêmes questions à tout voyage authentifié proposé. Il s'agit d'une pratique de révision, et non d'une réclamation concernant le stockage des informations d'identification ou la configuration de connexion de AnyTest. Une configuration moins répétée n'est utile que lorsque la suite protège toujours la limite d'authentification.