Accélérez vos tests
Techniques pour réduire le temps ajouté par Axe Watcher à votre suite de tests de bout en bout
Intégrer Axe Watcher dans votre suite de tests de bout en bout ajoute du temps car Watcher analyse chaque page visitée par vos tests. Si ce surcoût devient problématique, les techniques ci-dessous vous permettent de le réduire sans renoncer à la couverture qui vous tient à cœur.
Exclure les pages dont vous n'avez pas besoin de tester
Si votre suite de tests visite des pages que vous n'avez pas besoin de tester pour l'accessibilité (pages de connexion, pages tierces, tableaux de bord administrateur, flux de paiement gérés par une autre équipe), vous pouvez les ignorer entièrement en utilisant excludeUrlPatterns. Ignorer des pages entières est le moyen le plus efficace de réduire le temps de test.
JavaScript ou TypeScript :
axe: {
excludeUrlPatterns: [ 'https://example.com/login*', 'https://example.com/admin/**' ]
}Java :
AxeWatcherOptions options = new AxeWatcherOptions();
options.setExcludeUrlPatterns(new String[] {
"https://example.com/login*",
"https://example.com/admin/**"
});Voir Exclure les URL de l'analyse pour la syntaxe des modèles et des exemples de correspondance.
Limiter l'analyse à des sections spécifiques de la page
Au lieu d'analyser toute la page, utilisez runContext pour vous concentrer sur la section que votre test exerce. Par exemple, si un test ne couvre que le formulaire de paiement, il n'est pas nécessaire d'analyser la navigation, le pied de page ou la barre latérale.
JavaScript ou TypeScript :
axe: {
runContext: {
include: '.checkout-form',
exclude: '.site-navigation'
}
}Java :
AxeRunContext context = new AxeRunContext()
.setInclude(Arrays.asList(".checkout-form"))
.setExclude(Arrays.asList(".site-navigation"));
AxeWatcherOptions options = new AxeWatcherOptions();
options.setRunContext(context);Lorsque vous spécifiez des éléments à inclure via runContext, Axe Watcher analyse seulement les éléments correspondants. Si un sélecteur ne correspond à rien sur la page, rien ne sera analysé et aucun état de page ne sera capturé. Vérifiez vos sélecteurs avant de déployer cette configuration.
Voir (JavaScript/TypeScript) runContext ou (Java) AxeRunContext pour plus d'informations.
Désactiver les règles coûteuses
Certaines règles axe-core sont coûteuses en calcul. La règle color-contrast , par exemple, nécessite que le navigateur calcule la couleur rendue de chaque élément de texte visible sur la page, ce qui peut ajouter un temps significatif sur les pages riches en contenu.
Vous pouvez désactiver des règles spécifiques en utilisant runOptions.rules:
JavaScript ou TypeScript :
axe: {
runOptions: {
rules: {
'color-contrast': { enabled: false }
}
}
}Java :
Map<String, AxeRuleOptions> rules = new HashMap<>();
rules.put("color-contrast", new AxeRuleOptions().setEnabled(false));
AxeRunOptions runOptions = new AxeRunOptions();
runOptions.setRules(rules);
AxeWatcherOptions options = new AxeWatcherOptions();
options.setRunOptions(runOptions);Désactiver une règle signifie que les problèmes détectés par cette règle n'apparaîtront pas dans vos résultats. Envisagez de faire fonctionner les règles désactivées dans une suite de tests séparée et dédiée plutôt que de les ignorer définitivement.
L'utilisation de runOptions.rules (ou runOnly) génère un avertissement car ces paramètres peuvent entrer en conflit avec la configuration Axe globale de votre organisation. Voir Utilisation des options run avec runOnly ou Rules.
Voir (JavaScript/TypeScript) runOptions ou (Java) AxeRunOptions pour plus d'informations.
Utilisez le mode manuel pour contrôler quelles analyses les tests effectuent sur les pages
Par défaut, Watcher analyse automatiquement chaque page visitée par vos tests. Si la majorité de votre suite de tests visite des pages que vous n'avez pas besoin de vérifier, vous pouvez désactiver l'analyse automatique globalement et l'activer uniquement dans les tests qui en ont besoin.
JavaScript ou TypeScript :
axe: {
autoAnalyze: false
}Java :
AxeWatcherOptions options = new AxeWatcherOptions();
options.setAutoAnalyze(false);Avec l'analyse automatique désactivée, vous appelez analyze() explicitement où vous avez besoin d'un résultat, et utilisez start() / stop() pour entourer les sections de votre suite de tests où vous souhaitez que l'analyse automatique reprenne.
Voir Contrôler vos analyses pour des instructions complètes et des exemples.
Exécuter des tests en parallèle
Si votre infrastructure de test prend en charge l'exécution parallèle, exécuter votre suite de tests avec plusieurs travailleurs réduit le temps total de l'horloge murale. Watcher prend en charge les exécutants de tests en parallèle ; vous devez seulement vous assurer que chaque travailleur partage le même buildID non nul pour que leurs résultats soient combinés plutôt que remplacés.
Voir Exécution de tests en parallèle pour les instructions de configuration.
Résumé
| Technique | Idéal pour | Compromis |
|---|---|---|
| Exclure des pages | Pages que votre équipe ne gère pas ou n'a pas besoin de tester | Des pages importantes pourraient être oubliées par erreur |
| Limiter les sections de page | Grandes pages où seule une partie est pertinente pour votre test | Les problèmes en dehors des sections sélectionnées ne sont pas détectés |
| Désactiver les règles coûteuses | Les équipes constatent que certaines règles coûteuses ne s'appliquent pas à leur situation | Ces règles ne s'exécutent pas dans cette suite de tests |
| Mode manuel | Suites de tests qui visitent de nombreuses pages sans rapport avec les tests d'accessibilité | Nécessite des appels explicites analyze() / start() / stop() dans le code de test |
| Tests en parallèle | Équipes avec une infrastructure CI qui prend en charge les travailleurs parallèles | Nécessite de coordonner buildID entre les travailleurs |
