Setzen Sie den beabsichtigten Checkboxzustand.

Eine Einstellung ist vor dem Test aktiv. Der Test klickt zum Aktivieren und deaktiviert sie. Der Autor kopierte eine Geste ohne Ausgangszustand. Benennen Sie Umschalten oder gewünschten Endwert.

Der Aktionsleitfaden beschreibt Checkboxen, die Locator-API setChecked(). Bei richtigem Zustand kehrt es sofort zurück. Sonst handelt es und prüft den Zustand. Das passt zur Anforderung, eine erlaubte Testeinstellung aktiviert zu lassen.

Den Zielzustand ausdrücken

Unsere lokale Demo reminders beginnt einmal aktiviert, einmal deaktiviert. Beide Fälle verlangen dasselbe Ergebnis und verwenden eine wiederholende Assertion. Keine echten Meldungen, Berechtigungen oder Kontoeinstellungen ändern sich.

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

Runner und importiertes expect sind nötig. Geprüft wird der Elementzustand, keine Speicherung, Zustellung oder Servereinstellung. Ergänzen Sie solche Anforderungen über einen unterstützten Evidenzpfad.

Der lokale change-Zähler bleibt bei null, wenn setChecked(true) erneut auf die aktive Checkbox wirkt. Von deaktiviert folgt aktiviert mit einem Ereignis. Ein weiterer Zielaufruf ändert den Zähler nicht. Ein gewöhnlicher Klick deaktiviert danach.

Ausgangsanforderungen sichtbar halten

Zielsetzen kann einen unerwarteten Anfang verbergen, wenn dieser ungeprüft bleibt. Verlangt die Anforderung standardmäßig deaktiviert, prüfen Sie vorher. Für Umschaltabdeckung etablieren Sie Ausgangswert und passenden Übergang.

setChecked beweist nicht die Ausführung jedes Handlers. Sofortige Rückkehr beim richtigen Zustand braucht keinen Klick. Ein Test für change benötigt einen kontrollierten Gegenwert und die Wirkung als Assertion.

Die Methode erwartet passende Checkbox oder Radioeingabe. Hier ist es nativ. Eigene Schalter oder Buttons brauchen dokumentierte Semantik, nicht dieselbe API-Annahme. Tastatur und Zugänglichkeit prüfen Sie bei Bedarf getrennt.

Wiederholung braucht eine Sicherheitsgrenze

Die lokale Demo ist harmlos; echte Checkboxen können Requests, Meldungen oder Abrechnungsänderungen auslösen. Daraus folgt keine Erlaubnis für Produktionswiederholungen. Verwenden Sie genehmigte Stagingdaten und verstehen Sie Wirkung und Cleanup.

UI und gespeicherter Zustand können abweichen. Laden Sie neu oder lesen Sie autorisiert unabhängig, wenn Persistenz erforderlich ist. Erfassen Sie Anfang, Ziel, Oberflächenergebnis und Serverbelege.

AnyTest beschreibt Erkundung und überprüfbare Tests. Fragen Sie, ob ein Schritt einen Endzustand nennt oder aus unbekanntem Anfang umschaltet. Eine bestimmte Checkboximplementierung wird nicht behauptet.

Zustand und Ereigniszähler beantworten verschiedene Fragen. Behalten Sie beide, damit ein wiederholter Leerlauf nicht als weiterer Nutzerübergang gilt. Benennen Sie die notwendige Folgewirkung vor Abschlussbewertung.