Accélérez vos tests
Techniques pour réduire le temps que Axe Watcher ajoute à votre suite de tests de bout en bout
L'intégration d'Axe Watcher dans votre suite de tests de bout en bout ajoute du temps car Watcher analyse chaque page que vos tests visitent. Si cette charge devient problématique, les techniques ci-dessous vous permettent de la réduire sans renoncer à la couverture qui vous tient à cœur.
Exclure les pages que 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 administratifs, flux de paiement gérés par une autre équipe), vous pouvez les ignorer complètement 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 de motif et des exemples de correspondance.
Limiter l'analyse à des sections spécifiques de la page
Au lieu d'analyser la page entière, 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 la 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 d'axe-core sont coûteuses en calcul. La règle color-contrast, par exemple, nécessite que le navigateur calcule la couleur affichée de chaque élément texte visible sur la page, ce qui peut ajouter un temps significatif sur des pages chargées 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 dédiée séparé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 globale Axe de votre organisation. Voir Utiliser runOptions avec runOnly ou Rules.
Voir (JavaScript/TypeScript) runOptions ou (Java) AxeRunOptions pour plus d'informations.
Utiliser le mode manuel pour contrôler quelles tests analysent les pages
Par défaut, Watcher analyse automatiquement chaque page que vos tests visitent. Si la plupart 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 là où vous avez besoin d'un résultat, et utilisez start() / stop() pour encadrer 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 les tests en parallèle
Si votre infrastructure de tests prend en charge l'exécution parallèle, exécuter votre suite de tests avec plusieurs travailleurs réduit le temps total d'horloge murale. Watcher prend en charge les runners de tests parallèles ; vous devez seulement vous assurer que chaque travailleur partage le même buildID non nul afin que leurs résultats soient combinés plutôt qu'écrasés.
Voir Exécuter les tests en parallèle pour les instructions de configuration.
Résumé
| Technique | Idéal pour | Compromis |
|---|---|---|
| Exclusion de pages | Pages que votre équipe ne possède pas ou n'a pas besoin de tester | Des pages importantes pourraient être omises par erreur |
| Limiter les sections de page | Pages volumineuses où seule une partie est pertinente pour votre test | Les problèmes en dehors des sections sélectionnées ne sont pas trouvés |
| Désactiver les règles coûteuses | Les équipes trouvent 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 non pertinentes pour 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 en parallèle | Nécessite la coordination de buildID entre les travailleurs |
