Le sélénium et TestNG en Utilisant à la Fois des "dependsOn" et " priority =' Problème

Je suis en train de travailler sur la mise en œuvre de meilleur contrôle de workflow dans mon interface graphique de l'automatisation des tests. Et j'ai d'abord commencé avec dependsOn, mais a rapidement trouvé l'inconvénient est que si un test échoue, tout le reste de la suite n'est pas exécuté. Donc je suis passé à l'aide de la " priorité=' mais je vois un comportement inattendu. Un exemple:

@Test(priority = 10)
public void login(){...}

@Test(priority = 20, dependsOnMethods = "login")
public void verifyUserLogin() {...}

@Test(priority = 30, dependsOnMethods = "verifyUserLogin")
public void navigateToReportSettings() {...}

@Test(priority = 40, dependsOnMethods = "navigateToReportSettings")
public void verifyGeneralSettings() {...}

@Test(priority = 40, dependsOnMethods = "navigateToReportSettings")
public void verifyReportingPeriod() {...}
...
@Test(priority = 90, dependsOnMethods = "navigateToReportSettings")
public void saveReportSettings() {...}

Ce que je veux:

De connexion.
Vérifier l'utilisateur est connecté.
Accédez à la page paramètres de rapports.
Vérifier les paramètres généraux et la période de reporting sur le rapport des paramètres de la page (dans n'importe quel ordre)
Faire quelques modifications et les enregistrer.
Important: 10, 20, et 30 doivent réussir ou d'ignorer le reste. Si tout 40 échoue continuent à 50, une fois tous les 40 ont terminé. Mais sans dépendance sur toute l'étape des années 40 à réussir!

Ce qui se passe:

De connexion (priorité 10).
Enregistrer prioritaire (90).

Remarque: il existe également des "groupes" annotations, mais je ne pense pas que c'est pertinent ici.
Merci d'avance pour les conseils sur la façon de combiner la priorité et dependsOn avec succès pour le contrôle de flux de travail, mais avec des dépendances utilisées uniquement en cas de besoin.

Voici un autre exemple de code.
Je n'ai aucune idée pourquoi elle est en cours d'exécution dans cet ordre:
Sortie:
10, 20, 30, 40, etc... 110, //OK
130, 140, 150, 160, //Pourquoi les 120 priorités ignorés?
120, 120, 120, etc... 120 //Run-elle la dernière?
Il est également intéressant que le groupe de 120s peut être renumérotés de manière séquentielle (121, 122, 123, etc) et qu'ils sont encore dernier run.

Par conséquent, la question doit être que "dependsOn" et " priority =' ont tout simplement pas de bien jouer ensemble. Et je suis curieux de savoir si quelqu'un a eu ces deux travailler dans leur environnement. Qui sait, peut-être son un mais avec Intellij IDEA? De toute façon j'ai besoin d'aller au fond de cette bientôt à éviter de coûteuses refactoring plus tard! Merci encore pour tous vos commentaires - JR

@Test(priority = 10, groups = "A")
public void login(){
System.out.println("10");
}
@Test(priority = 20, groups = {"A", "B"})
public void openUserAdministrationTest() {
System.out.println("20");
}
@Test(priority = 30, groups = {"A", "B"})
public void usersTabTest() {
System.out.println("30");
}
@Test(priority = 40, groups = {"A", "B"})
public void createUserTabTest() {
System.out.println("40");
}
@Test(priority = 50, groups = {"A", "B"})
public void userCreationDataEntryTest() {
System.out.println("50");
}
@Test(priority = 60, groups = {"A", "B", "C"})
public void userRolesTest() {
System.out.println("60");
}
@Test(priority = 70, groups = {"A", "B"})
public void saveUserTest() {
System.out.println("70");
}
@Test(priority = 80, groups = {"A", "B"})
public void closeUserAdminAndLogoutTest() {
System.out.println("80");
}
@Test(priority = 90, groups = "A")
public void loginNavigateToUserAdmin() {
System.out.println("90");
}
@Test(priority = 100, groups = {"A", "D"})
public void verifyUserSearchUserReturned() {
System.out.println("100");
}
@Test(priority = 110, groups = {"A", "D"})
public void reOpenNewUserTest() {
System.out.println("110");
}
@Test(priority = 120, groups = {"A", "E"}, dependsOnMethods = "reOpenNewUserTest")
public void verifyNewUserUserNameTest() {
System.out.println("120");
}
@Test(priority = 120, groups = {"A", "E"}, dependsOnMethods = "reOpenNewUserTest")
public void verifyNewUserFullNameTest() {
System.out.println("120");
}
@Test(priority = 120, groups = {"A", "E"}, dependsOnMethods = "reOpenNewUserTest")
public void verifyNewUserDepartmentTest() {
System.out.println("120");
}
@Test(priority = 120, groups = {"A", "E"}, dependsOnMethods = "reOpenNewUserTest")
public void verifyNewUserPhoneNumberTest() {
System.out.println("120");
}
@Test(priority = 120, groups = {"A", "E"}, dependsOnMethods = "reOpenNewUserTest")
public void verifyNewUserEmailTest() {
System.out.println("120");
}
//     Note: password and active verified by user login
@Test(priority = 120, groups = {"A", "E"}, dependsOnMethods = "reOpenNewUserTest")
public void verifyNewUserActiveCheckedTest() {
System.out.println("120");
}
@Test(priority = 120, groups = {"A", "E"}, dependsOnMethods = "reOpenNewUserTest")
public void verifyNewUserLanguageTest() {
System.out.println("120");
}
@Test(priority = 120, groups = {"A", "E"}, dependsOnMethods = "reOpenNewUserTest")
public void verifyNewUserDateFormatTest() {
System.out.println("120");
}
@Test(priority = 120, groups = {"A", "E"}, dependsOnMethods = "reOpenNewUserTest")
public void verifyNewUserNumberFormatTest() {
System.out.println("120");
}
@Test(priority = 120, groups = {"A", "E"}, dependsOnMethods = "reOpenNewUserTest")
public void verifyNewUserReportingPeriodTest() {
System.out.println("120");
}
@Test(priority = 120, groups = {"A", "E"}, dependsOnMethods = "reOpenNewUserTest")
public void verifyNewUserReportingPeriodExampleTest() {
System.out.println("120");
}
@Test(priority = 120, groups = {"A", "E"}, dependsOnMethods = "reOpenNewUserTest")
public void verifyNewUserReferencePeriodTest() {
System.out.println("120");
}
@Test(priority = 120, groups = {"A", "E"}, dependsOnMethods = "reOpenNewUserTest")
public void verifyNewUserReferencePeriodExampleTest() {
System.out.println("120");
}
@Test(priority = 120, groups = {"A", "E"}, dependsOnMethods = "reOpenNewUserTest")
public void verifyNewUserShowAnnotationsCheckedTest() {
System.out.println("120");
}
@Test(priority = 130, groups = {"A", "C"})
public void verifyNewUserRoleTest() {
System.out.println("130");
}
@Test(priority = 140, groups = {"A", "C"})
public void verifyNewUserFunctionalRoleTest() {
System.out.println("140");
}
@Test(priority = 150, groups = {"A", "C"})
public void verifyUserAdminCloseAndLogoutTest() {
System.out.println("150");
}
@Test(priority = 160, groups = {"A", "C"})
public void verifyUserLogin() {
System.out.println("160");
}

C'est beaucoup plus simple exemple, mais aussi en montrant comment dépend tout simplement casse priorités:

@Test(priority = 10)
public void test10(){
System.out.println("10");
}
@Test(priority = 20, dependsOnMethods = "test10")
public void test20() {
System.out.println("20, depends on 10");
}
@Test(priority = 30, dependsOnMethods = "test20")
public void test30() {
System.out.println("30, depends on 20");
}
@Test(priority = 40, dependsOnMethods = "test10")
public void test40() {
System.out.println("40, depends on 10");
}

Doit s'exécuter: 10, 20, 30, 40.
Fonctionne: 10, 20, 40, 30.

Un test ne doit pas dépendre d'un autre test. Cela introduit des dépendances au sein de votre infrastructure de test. Dépendances = beaucoup de tracas, pas beaucoup de gain, de nombreux domaines de tomber sur. Mon conseil: combiner les tests.
Oui, j'ai entendu cet argument à plusieurs reprises... Cependant, il existe de nombreux cas lorsque les dépendances et les flux de travail qui doit être contrôlé. Par exemple le scénario où vous créez un utilisateur, fermez la session en tant qu'administrateur, connectez-vous comme nouvel utilisateur, créez un rapport, et de vérifier les autorisations des utilisateurs. Cela pourrait être un cas de test, mais il devrait vraiment être 10 ou 15 ans. Vous ne voulez pas l'ensemble de test à l'échec juste parce qu'il ya un problème avec dit le champ numéro de téléphone à la création d'un utilisateur de l'étape. Un échec de l'assertion échoue l'ensemble de cas de test. Par conséquent, la nécessité pour les flux de travail et des dépendances. Aussi, il minimise le code à répétition...
Dans le cas où si l'on doit envisager la combinaison de nombreux tests en un seul '@Test " où il y a trop d'Affirmations, alors envisager l'utilisation de soft affirmations. Ensuite, tout le code (lire Affirmations) sera effectuée, puis un échec se produit. Juste une suggestion pour un petit problème.
La raison pour laquelle il serait mauvais de garder tous les tests à l'intérieur d'un seul @Test est un Jack Ryan mentionne, l'autre étant la ré-utilisabilité de tests selon les différents scénarios. En particulier, dans les tests de l'INTERFACE utilisateur, il est tout au sujet de différents scénarios. Dans deux scénarios différents, il y AURA quelques tests qui sont toujours à la commune. Alors pourquoi devrions-le code de ces tests seront répétés autant de différents tests?
J'ai exécuté le code que vous avez donné et qu'il fonctionne comme prévu. Avez-vous manqué de quelque chose??

OriginalL'auteur M_Tech | 2013-09-04

2

Ne pas accorder la priorité et dépend de l'ensemble, vous pouvez regrouper les tests. Vous pouvez le faire comme
Par exemple,
```
@Test(priority = 10, groups = { "10" })
public void test10() {
System.out.println("10");
}
@Test(dependsOnMethods = "test10", groups = { "10" })
public void test20() {
System.out.println("20, depends on 10");
}
@Test(dependsOnGroups = { "10" })
public void test30() {
System.out.println("30, depends on 20");
}
@Test(dependsOnMethods = "test30")
public void test40() {
System.out.println("40, depends on 10");
}
```
Deuxième chose doit exécuter (réussir ou d'ignorer le reste)

Vous serez toujours courir après les méthodes dont vous avez besoin, même si certains d'entre eux ont échoué. Ceci est utile lorsque vous voulez juste assurez-vous que vos méthodes de test sont exécutées dans un certain ordre, mais leur succès n'est pas vraiment dépendre de la réussite des autres. Une douce dépendance est obtenu par l'adjonction de "alwaysRun=true" dans votre annotation @Test.

Si une méthode dépend échoue et que vous avez une dépendance matérielle (alwaysRun=false, ce qui est la valeur par défaut), les méthodes qui en dépendent ne sont pas marquée comme un ÉCHEC mais comme SKIP. Sauté méthodes seront signalées comme telles dans le rapport final (dans une couleur qui n'est ni rouge ni vert en HTML), ce qui est important puisque sauté méthodes ne sont pas forcément des échecs.

Si vous avez obtenu votre réponse que de l'accepter

OriginalL'auteur bangoria anjali
1

Il y a beaucoup de défauts liés à dependsOnMethods annotation. J'ai été confronté à la situation semblable dans 6.5.2. Essayez de mettre à jour votre dépendance à 6.8.3.

Entendez-vous mettre à jour votre "TestNG" à 6.8.3??
Oui, je le fais. TestNG 6.8.3 est la dernière version stable. (6.8.5 a quelques problèmes)
Je ne trouve pas un pré-construit jar version de TestNG 6.8.3, mais seule source sur github versions. Aurez à construire par moi-même??
S'il vous plaît, vérifiez de nouveau. Il y a un 6.8.3 dans maven repos
Je suis à l'aide de 6.8.5 donc, sauf si il y a un bug dans la dernière...

OriginalL'auteur Artem Yakovlev

Pour faire des tests de fonctionner même après il échoue, utilisez alwaysRun attribut avec dependsOnMethods au lieu d'utiliser priorité attribut, alwaysRun attribut laissez la prochaine dépendance à exécuter, même après qu'il échoue,essayez la syntaxe suivante:

@Test
public void login(){...}
@Test(dependsOnMethods = "login")
public void verifyUserLogin() {...}
@Test(dependsOnMethods = "verifyUserLogin")
public void navigateToReportSettings() {...}
@Test(dependsOnMethods = "navigateToReportSettings", alwaysRun=true)
public void verifyGeneralSettings() {...}
@Test(dependsOnMethods = "navigateToReportSettings", alwaysRun=true)
public void verifyReportingPeriod() {...}
...
@Test(dependsOnMethods = "navigateToReportSettings")
public void saveReportSettings() {...}

OriginalL'auteur Rishab

Vous devez vous connecter pour publier un commentaire.