Web Platform Tests et confiance dans les fonctions navigateur
Combinez Web Platform Tests, vérifications d’exécution et assertions applicatives pour évaluer une fonction navigateur.
Vous voulez la documentation structurée pour Plateforme ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
Web Platform Tests fournit une preuve de conformité dans des conditions déclarées, mais ne garantit pas chaque parcours applicatif. Séparez spécification, test partagé, vérification locale et signal visible de l’application. Une capacité ne révèle ni identité ni appareil.
Choisir la preuve WPT
Consultez le dépôt WPT et l’API testharness. Notez le chemin, la spécification, la version, l’origine, les permissions et la date. Un test omis, expérimental ou attendu en échec exige une alternative.
Lisez les métadonnées avec le résultat. Un test local peut différer selon le contexte sécurisé, le geste utilisateur ou la politique de permissions. Vérifiez licence, dépendances et nettoyage avant de réutiliser un fixture.
Vérification de capacité
Testez la méthode nécessaire juste avant l’appel. Distinguez absente, disponible, refusée, échouée et terminée. Une propriété présente ne prouve ni permission, ni service disponible, ni écriture serveur.
Conservez la saisie et proposez une action de repli accessible. Notez origine, contexte sécurisé, version, état, repli et résultat visible sans données étrangères.
Tableau de décision
| Observation | Décision | Résultat visible | Limite |
|---|---|---|---|
| WPT réussit dans la matrice | inclure le candidat | essayer après vérification | conformité déclarée |
| WPT omis ou expérimental | revoir les métadonnées | garder le repli | couverture de test |
| Méthode absente ou contexte bloqué | utiliser le repli | garder la tâche | capacité de la page |
| Appel refusé | classer une fois | afficher la récupération | comportement navigateur |
| Appel terminé | vérifier l’application | confirmer le signal visible | navigateur et application |
Fixture d’échec
Le fixture crée ses contrôles, simule uniquement l’API possédée, vérifie le texte visible et supprime les nœuds dans chaque branche. Ne modifiez pas une empreinte et n’envoyez pas d’identifiants.
async function tester() {
const h = document.createElement('div');
h.innerHTML = '<p id="etat"></p><button id="repli" hidden>Utiliser le repli</button>';
document.body.append(h);
const etat = h.querySelector('#etat');
const repli = h.querySelector('#repli');
try {
const ok = typeof navigator.share === 'function';
const resultat = ok
? await navigator
.share({ title: 'Élément synthétique', url: '/fixture' })
.then(() => 'termine')
.catch(() => 'echec')
: 'absent';
etat.textContent = resultat === 'termine' ? 'Terminé' : 'Utilisez le repli';
if (resultat !== 'termine') repli.hidden = false;
console.assert(etat.textContent && (resultat === 'termine' || !repli.hidden));
return resultat;
} finally {
h.remove();
}
}
Vérification applicative
Après l’appel, vérifiez le message, le contrôle ou l’enregistrement appartenant à l’application. Une promesse résolue ne prouve pas une écriture serveur. Séparez les résultats et testez focus, clavier, libellés et récupération.
Répétez la matrice après une version, une spécification, un contexte sécurisé, une permission ou un changement de harness. Conservez le chemin WPT, l’état, le repli et la date sans contenu personnel.
BotBrowser : portée
BotBrowser fournit des contextes contrôlés pour des parcours autorisés inspirés de WPT et des vérifications répétables. Un contexte isolé sépare l’état mutable et compare les résultats visibles.
Il ne certifie pas WPT, n’accorde pas de permissions, ne sécurise pas une origine, ne remplace pas l’infrastructure de conformité et ne prouve pas une transaction serveur. La documentation d’isolation BotBrowser démontre la répétabilité, pas une garantie universelle.
Voir aussi le guide de compatibilité des API et le guide WebDriver BiDi.
BotBrowser peut exécuter des vérifications répétables dans des contextes autorisés inspirés de WPT, mais ne garantit pas la conformité, n’accorde pas de permissions et ne remplace pas la preuve d’une transaction. Gardez les deux limites dans le rapport.
La confiance augmente quand chaque couche a un responsable: spécification, test WPT, matrice de navigateurs, application et fixture. Notez chemin, version, origine, état, repli et résultat visible.
Utilisez l’évidence négative honnêtement. Un test omis, un refus ou un délai doit être classé et ne doit pas devenir un succès caché. Gardez le repli jusqu’à preuve applicative suffisante.
Gardez une fiche concise avec le chemin WPT, la version, le contexte, l’état, l’assertion visible et le repli.
Comparez la version candidate à la précédente avec le même fixture et conservez le premier échec utile.
Indiquez le responsable et la date de revue pour chaque exception.
Nommez le repli visible afin que le support puisse reproduire le résultat.
Rendez le rapport lisible pour une personne qui n’a pas exécuté le navigateur et indiquez limite, résultat et prochaine action.
Cette explication évite de transformer une preuve étroite en promesse universelle.
Notez aussi la date et le responsable de la prochaine vérification.
Ce transfert maintient la confiance à jour.
Le résultat doit conserver la frontière entre conformité et comportement applicatif.
Ne présentez pas un contexte contrôlé comme une garantie universelle.
Sources
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.