Une vérification souple exige aussi un arrêt ferme.

Une page de revue affiche un mauvais titre et un mauvais état. Une assertion normale s'arrête au premier écart; une assertion souple peut recueillir les deux. C'est utile au diagnostic, mais le test reste en échec. Continuer l'exécution n'autorise pas la suite du processus produit.

Ce guide utilise la documentation des assertions Playwright et une page locale inventée. Aucune approbation, soumission ou compte réel. Plusieurs observations indépendantes précèdent une barrière avant le bouton représentant la suite.

Recueillez des observations encore pertinentes

Les assertions souples échouées poursuivent l'exécution mais marquent le test en échec. Elles fonctionnent avec le moteur de test Playwright, pas automatiquement avec une autre bibliothèque.

Une observation suivante doit rester pertinente après un écart. Un mauvais titre n'empêche pas de lire un état indépendant. Un dossier préalable absent est différent : lire ses champs peut produire des erreurs secondaires inutiles.

await expect.soft(page.getByRole('heading')).toHaveText('Review demo draft');
await expect.soft(page.getByRole('status')).toHaveText('Ready for review');
expect(test.info().errors).toHaveLength(0);
await page.getByRole('button', { name: 'Continue demo' }).click();

L'exemple suppose la page contrôlée et test et expect importés. La vérification ferme des erreurs est volontaire. Si une observation échoue, Continue n'est pas actionné. Ce bouton local ne définit aucune règle pour une véritable approbation.

Placez la barrière avant l'action dépendante

Arrêtez avant une action dont le sens dépend de l'état vérifié. Une barrière finale serait trop tardive : le mauvais dossier pourrait déjà être modifié. Choisissez selon les dépendances, pas pour allonger la liste des erreurs.

Les échecs sont disponibles dans test.info().errors. Ne videz pas ce tableau et ne modifiez pas le statut pour simuler un succès. Une capture ultérieure n'efface pas les échecs.

Gardez seulement les observations en lecture seule qui restent pertinentes et autorisées. Même une lecture authentifiée peut exposer des données dans les traces. Utilisez des dossiers de test autorisés et examinez les fichiers avant partage.

Vérifiez le cas négatif

Notre exemple comporte deux écarts. Le moteur les enregistre, puis la barrière arrête l'exécution. Une vérification après le test confirme que le bouton n'a jamais changé d'état. L'exécution attendue en échec reste présentée comme un échec, pas un succès de production.

Un autre cas fournit les bons états, franchit la barrière et modifie un marqueur local. Cela démontre le contrôle du flux, pas une protection serveur ni une règle universelle des tests générés.

Pour un prérequis de sécurité, une assertion ferme peut être plus simple. La souplesse sert au diagnostic, elle n'impose pas de retarder tout échec. Utilisez les deux formes selon leur comportement.

Laissez une règle de revue

Notez les observations indépendantes, l'action dépendante et le point d'arrêt. Cela révèle un parcours qui recueille des erreurs mais avance quand même.

AnyTest décrit exploration et tests pour revue humaine. Demandez si le test conserve son échec et protège les actions dépendantes. Aucune implémentation d'assertions souples d'AnyTest n'est affirmée. Plus de diagnostic ne doit pas affaiblir la barrière.