QA The Other WayAssurance qualité à l'ère de l'automatisation par IA. QA The Other Way.
QA pratique

Définissez l'état voulu de la case.

Utilisez un état final pour le résultat et testez le basculement séparément.

5 min de lectureQA The Other Way
Cases cochée et décochée arrivant au même état voulu.
Illustration éditoriale originale.
Vidéo d'illustration pour cet article. Texte en anglais à l'écran ; sélectionnez les sous-titres pour cette langue.

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

Utilisez un état final pour le résultat et testez le basculement séparément.
Exemple local inventé, pas une interface client ou fournisseur.

Une préférence est active avant le test. Le test clique pour l'activer et la désactive. Son auteur a copié un geste sans état initial. Précisez si le parcours demande un basculement ou une valeur finale.

Le guide des actions décrit les cases, et l'API Locator setChecked(). Si l'état est correct, la méthode revient immédiatement. Sinon, elle agit et vérifie. Cela convient à laisser active une préférence de test autorisée.

Exprimer l'état voulu

Demo reminders commence cochée dans un cas et décochée dans un autre. Les deux demandent le même état et une assertion réessayée. Aucun vrai message, compte ou permission ne change.

const reminders = page.getByRole('checkbox', { name: 'Demo reminders' });
await reminders.setChecked(true);
await expect(reminders).toBeChecked();

Runner et expect importé sont nécessaires. Nous prouvons l'état du contrôle, pas sauvegarde, livraison ou préférence serveur. Ajoutez ces exigences par une voie de preuve prise en charge.

Le compteur change reste zéro quand setChecked(true) revient sur une case cochée. Depuis décoché, elle se coche avec un événement. Répéter ne change pas le compteur. Un clic ordinaire la décoche ensuite.

Garder l'état initial visible

Définir l'état final peut cacher un départ inattendu. Si le défaut doit être désactivé, vérifiez avant activation. Pour tester le basculement, établissez le départ et l'action de transition.

setChecked ne prouve pas tous les gestionnaires exécutés. Le retour immédiat n'a pas besoin de clic. Observer change demande un départ opposé contrôlé et une assertion sur l'effet.

La méthode vise checkbox ou radio adaptés. Ici, case native. Un switch ou bouton personnalisé demande sémantique et interaction documentées. Ne supposez pas la même API partout. Séparez clavier et accessibilité.

Borner les répétitions

L'exemple local est sans conséquence ; une vraie case peut déclencher requêtes, notifications ou facturation. Il n'autorise pas les répétitions en production. Utilisez staging autorisé et comprenez effet et nettoyage.

L'interface peut différer du stockage. Rechargez ou lisez par une voie indépendante autorisée si la persistance compte. Notez départ, cible, résultat visible et preuves serveur.

AnyTest décrit exploration et tests à revoir. Demandez si le pas nomme un état final ou suppose un basculement depuis l'inconnu. Aucune implémentation précise n'est revendiquée.

État et compteur répondent à des questions différentes. Gardez les deux pour ne pas présenter un appel sans effet comme une nouvelle transition. Nommez l'effet suivant requis avant de conclure.

Questions courantes

setChecked(true) clique-t-il toujours ?

Non. Il revient immédiatement si la case est déjà cochée.

L'état coché prouve-t-il une préférence sauvegardée ?

Non. Persistance et effets suivants demandent leurs preuves.

Sources