Un échec attendu exécute toujours le test.
Distinguez défaut attendu, cas ignoré et succès inattendu.

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

Une équipe ignore un test dont l'échec est connu. Le corps ne tourne plus, le rapport ne montre pas si le défaut reste reproductible. Playwright a une annotation d'échec attendu : le test tourne et un succès devient inattendu.
Le guide des annotations distingue skip(), fail() et fixme(). skip ne tourne pas ; fail tourne et attend un échec. fixme convient à une exécution lente ou qui plante. Choisissez selon le sens du cas et ses limites opérationnelles.
Limiter le spécimen
Notre exemple compare deux chaînes fixes. L'écart est volontaire, sans défaut produit réel, action navigateur ni compte. Un autre exemple égalise les chaînes en gardant fail : succès inattendu et code de sortie non nul.
import { test, expect } from '@playwright/test';
test('controlled expected mismatch', async () => {
test.fail(true, 'Invented mismatch for annotation demonstration');
expect('actual demo value').toBe('expected demo value');
});Utilisez le runner Playwright, pas une exécution JavaScript ordinaire. Le rapport conserve erreur d'assertion et statut attendu. Une sortie réussie signifie ici que l'échec correspondait à l'attente, pas que les chaînes étaient égales.
Examiner l'erreur réelle
L'annotation n'attache pas l'échec à une assertion précise. Si la préparation échoue avant, le statut attendu peut correspondre sans atteindre le défaut. Simplifiez la préparation, lisez l'erreur et notez l'assertion exécutée. Une erreur inattendue d'authentification ou d'environnement n'est pas le défaut connu.
Pour un cas réel, gardez le comportement correct dans l'assertion, une référence vérifiable et un responsable. Ne modifiez pas l'assertion pour accepter le défaut. N'inventez pas de lien : cet exemple n'a qu'une description.
Limitez une annotation conditionnelle à la configuration touchée. Un défaut sur un navigateur ne justifie pas fail partout. Revoyez condition et statut avec les entrées, au lieu de les cacher dans un helper distant.
Examiner un succès inattendu
Un succès peut signaler une correction, un autre trajet ou une assertion affaiblie. Vérifiez avant de retirer l'annotation. Après confirmation, conservez une couverture normalement réussie plutôt qu'une exception permanente.
Le runner distingue écart attendu exécuté, égalité exécutée avec succès inattendu et corps ignoré non exécuté. Cela vérifie les annotations, pas la préparation d'une version produit.
Une exécution dangereuse ou coûteuse demande sa propre décision. L'échec attendu n'autorise ni actions destructrices, ni dépenses, ni données de production. Nommez la couverture ignorée et la raison de l'absence de vérification.
AnyTest décrit les tests revus par des humains. Examinez exceptions, assertions et préparation avec le même soin. Aucune intégration AnyTest particulière pour les défauts n'est revendiquée. Chaque exception réelle garde responsable et prochaine date de revue.
Questions courantes
test.fail ignore-t-il le corps ?
Non. Le test tourne et doit échouer.
L'échec attendu prouve-t-il le défaut visé ?
Non. Examinez l'erreur et l'assertion atteinte.