Exécution de tests en parallèle

This page is not available in the language you requested. You have been redirected to the English version of the page.
Link to this page copied to clipboard

Cet article décrit comment utiliser plusieurs lanceurs de tests avec Axe Watcher

Not for use with personal data

Certains frameworks de test exécutent les tests en parallèle par défaut, ce qui peut influencer vos résultats de tests d'accessibilité si cela n'est pas pris en compte. (Vous ne verrez que les résultats d'accessibilité du dernier test exécuté dans Axe Developer Hub.) Par exemple, bien que Playwright exécute par défaut tous les tests d'un seul fichier de manière séquentielle, il crée des travailleurs pour exécuter des fichiers de test individuels en parallèle. Il est également possible que votre organisation exécute son pipeline d'intégration continue en parallèle, ou vous pouvez vouloir exécuter votre suite de tests en utilisant des travailleurs parallèles pour accélérer le traitement.

Avec des lanceurs de tests en parallèle, vous devez vous assurer que chaque lanceur de tests reçoit le même buildID non nul car lorsque la propriété buildID est null (la valeur par défaut), les résultats de chaque lanceur de tests remplacer les résultats d'accessibilité existants pour le même SHA de commit Git, ce qui entraîne des données incomplètes dans Axe Developer Hub.

Lorsque buildID n'est pas null, des lanceurs de tests en parallèle avec le même buildID peuvent générer des résultats apparaissant comme un seul test dans Axe Developer Hub. Chaque lanceur de tests doit partager la même chaîne buildID non nulle afin que chaque lanceur de tests concatène (plutôt que de remplacer) ses résultats avec les résultats existants pour le même buildID et le SHA de commit Git.

Pour changer la valeur de buildID, utilisez :

Vous pouvez généralement obtenir une valeur buildID utilisable depuis votre fournisseur d'intégration continue. Par exemple, vous pouvez utiliser ces valeurs :

  • github.run_id

    Disponible dans les workflows GitHub. Consultez contexte GitHub dans la documentation GitHub pour plus d'informations.

  • CIRCLE_PIPELINE_ID

    Avec CircleCI, la valeur ci-dessus est disponible depuis l'environnement de votre processus. Consultez Variables d'environnement intégrées dans la documentation CircleCI pour plus d'informations.

    Autres variables d'environnement d'intégration continue que vous pouvez utiliser pour buildID :

    Fournisseur Variable d'environnement
    Bitbucket BITBUCKET_BUILD_NUMBER
    GitLab CI_PIPELINE_ID
    Jenkins BUILD_NUMBER

Is this page helpful?

Help us improve this page

Still need help?