Nommez les étapes selon la question à laquelle elles répondent.

Un rapport annonce Étape 1 réussie, Étape 2 réussie, Étape 3 échouée. L'ordre est conservé, mais peu expliqué. Un autre annonce Enregistré avec succès alors que le code a seulement cliqué. Le nom promet une conclusion non vérifiée.

Ce guide utilise l'API Playwright Test pour un parcours local inventé. Aucun compte ni serveur. Les limites du rapport doivent correspondre aux questions du code sans transformer un nom en preuve.

Donnez une question vérifiable à chaque étape

test.step groupe des actions dans une étape nommée. Le nom explique l'intention; l'assertion qui répond reste dans le corps. Lire la préférence actuelle est plus honnête qu'Enregistrée pour toujours lorsque seule une page est lue.

await test.step('Read the current demo preference', async () => {
  await expect(page.getByRole('status')).toHaveText('Demo preference: off');
});
await test.step('Enable the local demo preference', async () => {
  await page.getByRole('button', { name: 'Enable demo preference' }).click();
  await expect(page.getByRole('status')).toHaveText('Demo preference: on');
});

L'exemple suppose la démonstration et test et expect importés. Il établit les états locaux initial et modifié, pas une persistance serveur. Le titre, les étapes et la capture doivent conserver cette limite.

Séparez préparation et preuve

Ouvrir la page prépare. Lire l'état initial apporte une preuve. Cliquer agit; observer le nouvel état apporte une autre preuve. Tout regrouper sous Terminer le parcours cache le changement de question.

Trop de petites étapes ajoutent aussi du bruit. Une étape pour construire chaque localisateur n'explique pas le comportement produit. Groupez par question utile, pas par ligne ni par nombre arbitraire d'étapes.

L'imbrication peut montrer une vraie hiérarchie, mais n'enfouissez pas l'assertion sous des noms vagues. La revue doit la trouver sans ouvrir une chaîne Préparer, Traiter, Finir.

Renvoyez seulement la valeur nécessaire

L'API indique que test.step renvoie le résultat de son rappel. Cela garde un identifiant contrôlé près de son origine. Transmettez seulement ce que la suite exige, sans stockage global caché.

Validez la valeur. Un objet existant ne prouve pas le bon dossier. Nommez son origine et les assertions qui lui donnent son sens. Utilisez des données autorisées et évitez les noms privés dans les titres publics.

Vérifiez le rapport localement

Le moteur exécute deux étapes et vérifie les deux états. Une capture contrôlée montre le résultat local. Leur succès ne prouve pas une persistance distante. Le film explique la structure, ce n'est pas un enregistrement client.

En cas d'échec, le nom localise la question sans remplacer les détails. Lisez assertion et contexte. Toutes les actions d'une étape réussie ne sont pas forcément validées séparément. Des clics seuls peuvent réussir sans confirmer le résultat promis.

Examinez noms et code ensemble

Règle courte : titre exprimant la question, corps contenant action et assertion pertinentes, portée honnête. Actualisez les noms quand l'implémentation change. Une étiquette périmée peut tromper malgré un code correct mais plus limité.

AnyTest décrit exploration et tests pour revue. Demandez si les noms correspondent aux preuves recueillies. Aucun format d'étapes d'AnyTest n'est affirmé. Les noms facilitent la lecture; les assertions portent toujours la preuve.