Une étiquette sélectionne des tests, elle ne prouve pas la couverture.
Traitez les filtres comme un contrat explicite et indiquez ce qui reste exclu.

Édition traduite. Les identifiants techniques restent sous leur forme originale.

Un pipeline exécute @critical et devient vert. Quelqu'un appelle cela couverture complète de régression. L'étiquette a sélectionné un sous-ensemble sans prouver qu'il représente tous les parcours importants. Sélection et jugement du risque sont différents.
Ce guide suit la documentation des annotations Playwright avec deux tests locaux inventés, l'un pour une petite revue, l'autre pour une inspection plus large. Aucun résultat de pipeline réel ni pourcentage de couverture n'est revendiqué. Nous rendons l'appartenance visible.
Définissez le sens de l'étiquette
Playwright accepte les étiquettes dans les détails ou le titre. Elles commencent par @ et permettent le filtrage. Donnez à chaque convention un sens bref, par exemple un ensemble convenu pour une barrière précise.
Ne laissez pas @critical dépendre de l'opinion du dernier auteur. Nommez le responsable, les parcours inclus et les exclusions. Ajouter une chaîne est facile; justifier l'appartenance est le travail.
import { test, expect } from '@playwright/test';
test('demo title contract', { tag: '@demo-review' }, async () => {
expect('Demo review').toBe('Demo review');
});
test('demo archive contract', { tag: '@demo-wide' }, async () => {
expect(['draft', 'archive']).toContain('archive');
});Ces exemples montrent métadonnées et sélection, pas une application ni une couverture utile. Listez avant l'exécution :
npx playwright test demos/selection.spec.mjs --grep @demo-review --listLa vérification locale sélectionne seulement le contrat du titre. Son exécution valide une assertion inventée. Le contrat d'archive exclu ne compte pas comme preuve exécutée, même présent dans les sources.
Séparez sélection, exclusion et échec attendu
skip et fixme n'exécutent pas le test. fail l'exécute avec un échec attendu; un succès inattendu est signalé. Ces états diffèrent de l'absence due au filtre.
Distinguez sélectionnés, exécutés, ignorés et échecs attendus. Ne les additionnez pas dans un chiffre rassurant. Le silence peut signifier exclusion, désactivation ou succès réel.
Les tests focalisés limitent aussi la suite : lorsqu'ils existent, eux seuls tournent. Un focus de débogage local ne doit pas réduire silencieusement la suite partagée. Examinez les changements de sélection avec ceux du code.
Vérifiez l'ensemble lorsqu'il change
Contrôlez l'appartenance d'un nouveau parcours. Renommer un titre, changer une étiquette ou une expression régulière peut changer la sélection sans toucher le corps. Utilisez la liste du moteur avec la commande exacte du pipeline.
Les filtres complexes demandent leurs propres vérifications. Ne déduisez pas la sélection d'un fichier ou d'un tableau de bord. Conservez commande, configuration pertinente et noms sélectionnés avec le résultat.
Gardez le résultat dans sa portée
Une petite barrière peut répondre vite pendant qu'une suite large tourne ailleurs. C'est un plan, pas la preuve qu'elle détecte tout. Le risque produit décide la division, à revoir lorsque fonctions et échecs changent.
AnyTest décrit des agents découvrant des parcours et produisant des tests révisables. Examinez l'appartenance autant que les assertions. Aucune interface d'étiquettes d'AnyTest n'est affirmée. Un résultat honnête ne tire pas sa confiance des tests non exécutés.
Questions courantes
Un sous-ensemble vert prouve-t-il une couverture complète ?
Non. Il ne concerne que les vérifications sélectionnées et exécutées dans cette configuration.
Un test filtré équivaut-il à un test ignoré ?
Non. Sélection, skip/fixme et échec attendu sont des états distincts.