Une localisation autorisée n'est qu'un cas de test.
Séparez permission, coordonnées contrôlées et solution de repli avant de déclarer le parcours couvert.

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

Une page utilisant la position fonctionne parce que le test accorde toujours la permission. La suite connaît un environnement commode, pas toute l'expérience. Sans position utilisable, quelqu'un peut rester en attente ou perdre la saisie manuelle. Lire des coordonnées ne prouve pas ces solutions de repli.
Ce guide utilise la documentation d'émulation de Playwright et l'API BrowserContext pour un lecteur local inventé. Les coordonnées sont contrôlées, pas la position actuelle d'une personne. Aucun fournisseur de cartes, commande ou compte n'intervient. Nous séparons permission, position et réponse de l'interface à l'indisponibilité.
Permission et position sont deux entrées
Accorder la géolocalisation ne définit pas les coordonnées. Fournir des coordonnées n'accorde pas le droit de les lire. Configurez les deux dans un contexte jetable et limitez la permission à l'origine connue.
const context = await browser.newContext({
geolocation: { latitude: 0, longitude: 0 }
});
await context.grantPermissions(['geolocation'], {
origin: 'http://localhost:4179'
});
const page = await context.newPage();
await page.goto('http://localhost:4179/');
await page.getByRole('button', { name: 'Read demo location' }).click();
await expect(page.getByRole('status')).toHaveText('Demo coordinates: 0, 0');
await context.close();L'exemple nécessite un serveur local à cette origine et les fixtures browser et expect de Playwright. Les zéros sont des entrées de test évidentes, pas une adresse de livraison conseillée. La page affiche les nombres reçus sans déduire lieu réel, zone desservie ou précision physique.
La documentation avertit que les permissions prises en charge varient selon navigateur et version. Vérifiez le moteur exact. Un succès Chromium ne certifie ni un autre moteur, ni un système mobile, ni un appareil physique.
Rendez l'indisponibilité observable
L'API documente setGeolocation(null) pour émuler une position indisponible. Dans un cas séparé, appliquez cette entrée et laissez le rappel d'erreur afficher Position indisponible et un champ manuel. La démonstration utilise un délai borné.
Vérifiez que le repli est visible et utilisable, pas seulement que le rappel a eu lieu. Le test local remplit la zone manuelle avec Invented area. Il prouve une saisie utilisable après l'erreur, pas qu'un vrai service accepte cette zone.
N'appelez pas cela un test de refus. Permission accordée avec position indisponible est une autre configuration. Invite de permission, restriction de politique, capteur indisponible et délai dépassé peuvent produire des interfaces proches avec des causes différentes. Ajoutez le refus explicite dans une configuration prise en charge et vérifiée si le produit l'exige.
Réinitialisez le contexte, pas le sens du cas
Les permissions forcées appartiennent au contexte. clearPermissions() les efface, mais ne démontre pas qu'une personne a refusé. Utilisez des contextes neufs pour les scénarios indépendants et décrivez les entrées fournies.
Incluez l'origine réelle de la démonstration. Sans origine, la permission est plus large que nécessaire. Ne transférez pas une permission locale à un autre site ou à un navigateur authentifié partagé. Un contexte jetable rend sa portée plus facile à examiner.
Le produit peut conserver une ancienne position ou proposer la saisie manuelle avant la permission. Convenez des attentes avec l'équipe. Une lecture positive ne couvre pas positions périmées, seuils de précision ou mises à jour ultérieures.
Examinez le repli comme un parcours produit
Nommez le cas autorisé, l'indisponibilité et tout refus vérifié séparément. Précisez l'action suivante attendue. Si la saisie manuelle est promise, vérifiez son étiquette et l'acceptation de l'entrée autorisée de test à l'étape suivante.
AnyTest décrit exploration et tests pour revue humaine. Demandez quelle permission, quelles coordonnées et quel repli le parcours utilise. Aucune API de permissions d'AnyTest ni validation sur appareil physique n'est affirmée. Une couverture utile exige un environnement explicite et un repli traité comme un vrai parcours.
Questions courantes
La permission de géolocalisation fournit-elle une position réelle ?
Non. Permission et position contrôlée sont distinctes; la démonstration n'établit aucun emplacement physique réel.
Une position indisponible équivaut-elle à un refus ?
Non. Testez et nommez les causes séparément. Effacer les permissions forcées ne prouve pas un refus explicite.