Hygiène des données et de l’état pour l’automatisation du navigateur

Un test fiable nomme chaque entrée, propriétaire, résultat observable et limite de nettoyage. Un contexte neuf n’isole pas un compte partagé, un enregistrement serveur ou un répertoire de téléchargement. Utilisez des données synthétiques créées par une interface de test documentée, jamais des données personnelles ou des identifiants réels. Consultez le guide des fixtures et de l’isolement.

Matrice de propriété

Ressource	Créateur	Propriétaire mutable	Résultat observable	Limite de nettoyage
Compte synthétique	service de test	worker du scénario	titre ou accès	API de réinitialisation
Contexte et cookies	fixture	fixture	contexte vierge	fermeture dans finally
Référence d’état	dépôt	copie de fixture	route chargée	garder la référence; supprimer la copie
Répertoire d’artefacts	worker	worker	reçu court	supprimer le chemin local
Tâche distante	application	service	statut documenté	annuler ou attendre l’expiration

La fermeture locale ne prouve pas la suppression distante. Chargez une référence en lecture seule et écrivez une copie nommée par worker et tentative. Deux contextes peuvent encore modifier la même donnée; séparez les enregistrements ou sérialisez la mutation prévue.

Fixture d’échec

Une page synthétique sans marqueur de disponibilité vérifie le chemin d’erreur et le nettoyage :

import os from 'node:os';
import path from 'node:path';
import { mkdtemp, rm } from 'node:fs/promises';
import { chromium } from 'playwright';
import { expect } from '@playwright/test';

const dir = await mkdtemp(path.join(os.tmpdir(), 'state-hygiene-'));
const browser = await chromium.launch({ headless: true });
const context = await browser.newContext({ baseURL: 'http://fixture.test' });
const page = await context.newPage();
await page.route('/fixtures/without-ready-marker', route =>
  route.fulfill({ status: 200, contentType: 'text/html', body: '<main><p>Waiting</p></main>' })
);
let failure;
const remember = (label, error) => {
  const current = new Error(`${label}: ${error.message}`, { cause: error });
  failure = failure ? new AggregateError([failure, current], `${failure.message}; ${label} failed`) : current;
};
try {
  await page.goto('/fixtures/without-ready-marker');
  await expect(page.getByRole('status')).toHaveText('Ready', { timeout: 250 });
} catch (error) {
  remember('assertion de fixture', error);
} finally {
  try {
    await context.close();
  } catch (error) {
    remember('fermeture du contexte', error);
  }
  try {
    await rm(dir, { recursive: true, force: true });
  } catch (error) {
    remember('nettoyage de l’artefact', error);
  }
  try {
    await browser.close();
  } catch (error) {
    remember('fermeture du navigateur', error);
  }
}
if (failure) throw failure;

Tableau de décision

Observation	Catégorie	Action	Non démontré
Référence absente	fixture	échouer et réparer l’entrée	disponibilité du service
Ancien cookie visible	état navigateur	abandonner le contexte	invalidation serveur
Écriture concurrente	données de test	séparer ou sérialiser	défaut d’isolation navigateur
Assertion réussie, nettoyage échoué	infrastructure	garder les deux erreurs	suppression distante
Nouvelle tentative réussie	résultat incertain	consulter le statut admis	innocuité du premier essai

Revoir les transitions

Considérez l’état comme une séquence entre référence, observation et nettoyage. Un changement de compte exige la sortie prévue puis un nouveau contexte; effacer le stockage local ne révoque pas une session distante. Versionnez les références et refusez une copie incomplète plutôt que de la régénérer silencieusement.

Protéger secrets et artefacts

Les snapshots peuvent contenir des cookies. Limitez leurs permissions et gardez un reçu bref avec scénario, worker, résultat et nettoyage. N’écrivez ni tokens ni contenu de page. La rétention CI et le répertoire temporaire ont des propriétaires distincts. Voir aussi le guide des transferts de fichiers.

Revoir reprises et parallélisme

Nommez les fichiers par scénario, worker et tentative, sans identifiant personnel. Après un timeout, consultez le statut prévu avant de répéter une mutation. Après une mise à jour, testez contexte vierge, état expiré, changement de compte, sortie parallèle et échec de nettoyage.

La répétabilité vient d’entrées contrôlées, non d’un navigateur partagé durablement.

Fixez la route, le schéma de fixture, la forme de l’enregistrement synthétique et la configuration utile.

Chaque différence se rattache alors à l’application, à la fixture ou au runner.

Évitez une préparation globale qui crée des comptes, accorde des permissions et laisse des pages ouvertes.

Cette préparation mélange la cause du premier échec et les effets de tests précédents.

La fixture de démarrage indique un état connu chargé ou une connexion documentée terminée.

Elle ne doit pas imprimer le matériel de session utilisé.

La fixture de données indique l’étiquette du scénario et le résultat de réinitialisation.

Elle ne doit pas énumérer des enregistrements pour en trouver un qui passe.

Une entrée absente est un échec de fixture.

Un substitut imprévu rend le résultat non reproductible.

Certains états vivent hors navigateur, comme une boîte de messagerie simulée ou un service de notification.

Chaque dépendance possède son espace synthétique et son reçu.

Le navigateur peut observer une confirmation sans affirmer chaque livraison aval.

Utilisez l’interface de test du service pour les faits qui lui appartiennent.

Fermer une page libère ses listeners et handles.

Fermer un contexte libère l’état géré par ce contexte.

Ces actions ne suppriment pas seules un fichier copié, un objet téléversé ou un token d’un autre appareil.

Effectuez la déconnexion prévue tant que la page est disponible.

Fermez ensuite les ressources navigateur puis le répertoire local du worker.

Un échec de nettoyage applicatif peut être distinct de la fermeture du navigateur.

Conservez les deux observations dans le reçu.

Ne recherchez pas des profils, répertoires ou contextes au nom voisin pour élargir le nettoyage.

La récupération peut mettre en quarantaine son répertoire connu quand sa suppression échoue.

Un enregistrement synthétique doit être identifiable sans imiter des données personnelles.

Utilisez un préfixe de scénario, une étiquette d’exécution et des valeurs prévues pour l’assertion.

Pour une limite, modifiez une seule propriété déclarée de l’entrée.

Une réinitialisation restaure une référence connue et ne devine pas une réparation partielle.

Ne réutilisez pas automatiquement une étiquette dont le reçu signale un nettoyage incomplet.

Une assertion décrit ce qu’une personne ou un test autorisé peut voir.

Ne déduisez pas une session distante d’une entrée vide du stockage local.

Ne déduisez pas une tâche asynchrone d’une navigation terminée.

Enregistrez le signal manquant, le statut visible inattendu ou la catégorie d’erreur documentée.

Vérifiez d’abord enregistrement unique, contexte unique et répertoire privé avant de modifier les délais.

La revue périodique compare le reçu en échec au contrat déclaré avant de modifier une attente.

Capacité et limite de BotBrowser

BotBrowser fournit des BrowserContexts isolés avec cookies, stockage et état de session séparés pour des scénarios synthétiques autorisés. Cela permet de vérifier l’absence d’état client hérité; voir la documentation d’isolation multi-compte. BotBrowser ne remplace ni le cycle de vie Playwright/Selenium, ni le nettoyage applicatif, ni l’invalidation serveur, ni la gestion des secrets. Il ne garantit pas l’acceptation d’un cookie expiré, l’annulation d’une tâche ou l’effacement d’un enregistrement fournisseur.

Conservez seulement le scénario, le worker, le résultat visible et le nettoyage. Vérifiez un contexte vierge, un état expiré et cet échec forcé avant intégration.

Sources

• Playwright : bonnes pratiques
• OWASP Web Security Testing Guide
• BotBrowser : isolation multi-compte