J'ai téléchargé et exécuté avec succès mes tests sur la batterie d'appareils AWS. Localement, j'utilise des choses amusantes comme @Test (enabled = false, dependOnGroups = "Login") pour marquer les tests à exécuter à ce moment et dans quel ordre ils doivent exécuter. Localement, tout cela fonctionne bien et dandy comme prévu. Le problème se produit après avoir téléchargé le zip de la version maven dans la batterie de périphériques et effectué un test.

En regardant les journaux de la batterie de périphériques, peu importe si "enabled" est défini sur true ou false, il exécutera les choses quoi qu'il en soit. Il ignore également les annotations "group =" et "dependOnGroups". C'est très important, car tous les autres tests échoueront si je ne suis pas connecté en premier. Pire encore, les tests échouants suivants ne seront pas ignorés, donc AWS me facture volontiers plus d'argent.

J'ai essayé d'utiliser @Test (priority = blah), mais je l'ignore aussi. La seule chose qu'il semble respecter, ce sont des choses comme @BeforeSuite et @AfterSuite.

Quelqu'un a-t-il rencontré cela ou a-t-il une idée de pourquoi cela se produit?

4
Furfire 4 janv. 2016 à 23:42

2 réponses

Meilleure réponse

Je suis ingénieur travaillant sur AWS Device Farm.

1) indicateur d'annotation "activé"

Je viens de vérifier que vous avez raison à propos de notre analyseur TestNG en ignorant le drapeau "activé" sur les annotations et en incluant toujours le test, même s'il est désactivé. À première vue, cela semble être un problème simple avec une solution simple. Dans le meilleur des cas, nous essaierons de le réparer et de le mettre en production dès que possible.

2) Champ d'annotation "dependOnGroups"

La réponse à celle-ci est un peu plus complexe. À partir d'aujourd'hui, AWS Device Farm ne prend pas en charge les champs d'annotation dependOnGroups ou dependOnMethods .

Il y a plusieurs raisons à cela, la principale raison étant qu'AWS Device Farm exécute chaque méthode @Test individuellement, chacune utilisant une nouvelle instance du serveur Appium. Il y a des avantages / inconvénients à cette approche que je ne vais pas approfondir ici, mais je dirai qu'elle présente des avantages à la fois au niveau technique et fonctionnel. Lors de l'exécution de méthodes individuelles avec le runner TestNG, il ne chargera que le contexte d'une méthode individuelle, et non tous les tests / suites / groupes des dépendances spécifiées trouvés dans le fichier .jar. De plus, comme chacune de ces méthodes de test est exécutée dans un processus Java différent à chaque fois, le coureur TestNG ne maintient aucun "état" en mémoire. Cela signifie qu'il ne sait pas qu'il a déjà exécuté un test précédemment (dans un processus différent), il tentera donc de l'exécuter à nouveau.

3) Exécution de "groupes" de tests

Nous n'exposons actuellement pas groups/excludegroups à l'utilisateur pour lui permettre de sélectionner des collections spécifiques de tests à exécuter ou à ignorer. Cependant, cela devrait être possible en configurant vos entrées <groups> dans un fichier testng.xml placé à la racine de votre fichier *-tests.jar qui est téléchargé dans l'archive de votre package de test. Dans ce cas, notre analyseur ne doit "découvrir" que les tests définis dans ces groupes et non toutes les méthodes annotées @Test. Je n'ai cependant pas essayé ce cas précis, donc votre YMMV.


J'espère que ça t'as aidé! Si vous avez des questions supplémentaires ou si vous souhaitez que nous examinions un package d'exécution / test spécifique, n'hésitez pas à contacter ou à coller une URL vers une exécution précédemment exécutée.

3
ahawker 8 janv. 2016 à 18:52

J'ai ajouté testng.xml à la racine de * -tests.jar et vérifié.

Mais la batterie de périphériques n'exécute pas les tests répertoriés dans testng.xml. Il exécute toujours toutes les classes avec l'annotation @Test

-2
Terminator 19 févr. 2016 à 11:21