Existe-t-il une infra prête à l'emploi pour exécuter des tests de concombre en parallèle? [dupliquer]

Voici une approche qui a bien fonctionné pour moi (note importante: utiliser maven comme gestionnaire de construction)

===========================================

Vous aurez besoin d'avoir Maven et Firefox installés sur votre machine pour exécuter cet exemple.

Une fois que vous avez récupéré la source, vous pouvez l'exécuter en naviguant dans le répertoire Cucumber-JVM-Parallel et en émettant la commande:

Installation propre Mvn

Cela exécutera l'exemple de projet et démarrera deux navigateurs windows simultanément. Chaque fenêtre du navigateur correspond à un fichier de fonctionnalités de concombre dans l'exemple. Une fois l'exécution terminée, un rapport aura été généré dans /target/cucumber-report/index.HTML.

Le reste de ce post va aller plus en détail sur la structure de l'exemple de projet, bien qu'il soit supposé que vous avez une certaine expérience du concombre. Sinon, le readme Cucumber-JVM est un excellent point de départ.

Fichiers de fonctionnalités

La première chose dont vous avez besoin est votre fichiers d'entités pour décrire le comportement que vous attendez. Dans cet exemple, nous avons deux fonctionnalités distinctes, bien que vous puissiez également exécuter des scénarios dans une seule fonctionnalité en parallèle.

La façon dont nous pouvons le faire est d'utiliser des balises de concombre, qui peuvent être appliquées à tous les scénarios d'une fonctionnalité ou à des scénarios individuels.

Ci-Dessus, vous pouvez voir que nous avons deux fichiers de fonctionnalité. Ceux-ci résident dans le dossier ‘src/test/resources’. Chaque fichier d'entités est étiqueté (@autocorrect et @search), et contient un seul scénario.

Code de colle

Maintenant que nous avons nos scénarios, nous devons ajouter du code glue pour lier chaque étape à notre framework de test sous-jacent

Ceux-ci sont appelés définitions d'étape, et peuvent être trouvés dans ‘src/java/cucumber.jvm.parallèle/concombre/stepdefs’.

Dans l'extrait ci-dessus, vous pouvez voir que nous utilisons une instance de ShareDriver pour communiquer directement avec une fenêtre de navigateur. Ceci est basé sur l'un des exemples de concombre pour partager une seule session de navigateur entre tous les tests (en utilisant l'injection de dépendance) pour supprimer la nécessité de démarrer une instance de navigateur par test et ainsi accélérer l'exécution. Dans notre cas, cela se traduit par une session de navigateur par thread. La classe ShareDriver se trouve dans ‘/src/test/java / cucumber.jvm.parallèle/concombre’.

Objets de page

L'extrait montre également que nous utilisons une instance de 'SearchPageObject'’ qui est simplement une classe qui représente la page de recherche Google, trouvé dans " /src/test/java/concombre.jvm.parallèle/pageobjects’.

Ce n'est pas nécessaire, mais il est recommandé d'utiliser le modèle d'objet page pour faciliter la maintenabilité sur un projet plus grand.

Ci-dessus, vous pouvez voir que l'objet page contient des identifiants pour les éléments de la page ainsi que des méthodes spécifiques à cette page.

Coureurs

La prochaine étape du processus consiste à ajouter les coureurs de test. Nous utilisons JUnit par opposition à la CLI, et c'est où nous devons commencer à structurer les choses spécifiquement pour gérer l'exécution parallèle des tests.

Dans l'extrait ci-dessus de ‘SearchAT.classe ' vous pouvez voir que nous spécifions l'emplacement des fichiers d'entités. Nous spécifions également une balise (@search) qui se rapporte à l'une de nos balises de fichier de fonctionnalités cucumber et une destination de rapport html pour les résultats des tests.

Cela dit "exécutez tous les tests étiquetés comme @search et écrivez les résultats dans le dossier /search".

On a alors une autre classe, 'AutoCorrectAT' qui fait la même chose pour tous les tests étiquetés ‘@autocorrect’. Ces deux classes peuvent être trouvés sous ‘/src/test/java/concombre.jvm.parallèle/concombre’.

L'ajout d'un autre thread consiste simplement à ajouter une nouvelle classe runner avec une balise différente.

Essais parallèles

Jusqu'à présent, les instructions sont identiques à la création d'un ensemble non parallèle relativement simple de tests Cucumber-JVM utilisant WebDriver pour interagir avec un site.

Nous devons maintenant aller dans le fichier Maven POM pour voir comment nous effectuons les tests en parallèle.

Dans l'extrait ci-dessus, vous pouvez voir que le plugin maven-surefire est utilisé pour exécuter nos tests d'acceptation – toutes les classes qui se terminent par *AT seront exécutées en tant que classe de test JUnit. Grâce à JUnit, faire fonctionner les tests en parallèle est maintenant un cas simple de réglage de l'option de configuration forkCount. Dans l'exemple de projet, c'est 5, ce qui signifie que nous pouvons fonctionner jusqu'à 5 threads (c'est-à-dire 5 classes de coureur) à la fois.

============================

Plus de détails que vous pouvez obtenir dans Exécutant des tests Cucumber-JVM en parallèle article

J'espère que cela vous aidera.

Je suppose que vous utilisez une tâche de test pour exécuter vos coureurs de concombre? Si oui, vous pouvez l'utiliser dans votre build.gradle:

tasks.withType(Test) {
    maxParallelForks = 5
}

task uiTests(type: Test){  includes = ['**/*Cucumber*'] }

Cette tâche uiTests suppose que toutes les classes Runner ont un concombre dans leur nom, si cela ne vous convient pas, vous pouvez simplement écrire chaque classe Runner là-dedans.

Maintenant, si vous fournissez un propre coureur pour chaque fichier d'entités, les différents coureurs seront exécutés en parallèle

Vous pouvez donner à chaque caractéristique une balise différente en haut, puis laisser chaque coureur n'exécutez qu'une seule balise. Cela peut être configuré comme

@CucumberOptions{tags = @Feature1}

Dans chaque classe de coureur