Échec d'assertion: Échec de test de l'interface utilisateur - Échec d'extraction des attributs pour l'élément
Lors du test de l'interface utilisateur dans Xcode (7.2 et 7.3), mes tests échouent parfois avec une erreur plutôt générique:
Échec d'assertion: Échec de test de l'interface utilisateur - Échec d'extraction des attributs pour l'élément
J'ai tendance à avoir cette erreur en appelant .hittable ou .tap() sur un élément mais je ne peux pas dire pourquoi. J'ai vérifié que les paramètres d'accessibilité des éléments que je gère sont correctement configurés et que toutes les vues de conteneur dans lesquelles ils se trouvent ne sont pas activés. Hélas, cela ne semble pas résoudre le problème.
Le journal de la console révèle:
UI Testing Failure - Failure fetching attributes for element <XCAccessibilityElement: 0x7e68ae50> pid: 89032, context: 4D9272C7-3024-4062-B0FA-E16EF426F17A, payload: {
pid = 89032;
"uid.elementID" = 1432;
"uid.elementOrHash" = 2125772976;
}: Error Domain=XCTestManagerErrorDomain Code=13 "Error copying attributes -25202" UserInfo={NSLocalizedDescription=Error copying attributes -25202}
J'ai essayé de chercher et j'ai trouvé que c'était déjà enregistré mais il ne semble pas y avoir de solution actuelle ( lien radar ) même pour Xcode 7.3.
Il semble que parfois, si je redémarre le simulateur/le périphérique, cette erreur ne se produit pas, mais ce n'est pas une solution intéressante.
Vous pouvez utiliser temporairement XCUICoordinate.tap() comme alternative. Par exemple, remplacez button.tap() par button.coordinateWithNormalizedOffset(CGVector(dx: 0.5, dy: 0.5)).tap().
J'ai rencontré le même problème et la solution de contournement fonctionne pour moi.
J'ai ce problème. Il est apparu après un correctif, j'ai donc compris ce qui pouvait causer cela dans mon cas.
Dans mon application, j'ai l'écran principal. Son contenu est renvoyé par le serveur et mis en cache sur l'appareil. Cet écran conduit l'utilisateur à différents écrans «détaillés». Chaque fois que l'utilisateur revient de l'écran détaillé, la méthode viewDidAppeare est appelée sur l'écran principal. Dans cette méthode, l’écran principal demande du contenu. Pour fournir du contenu, 'Data Manager' doit extraire de la base de données ou demander au serveur 2 entités différentes dans un ordre strict afin qu'il utilise dispatch_group. L'écran principal reçoit une notification du nouveau contenu de l'appel dispatch_group_notify, c'est pourquoi il est asynchrone. Jusqu'au moment où dispatch_group_notify est exécuté, viewDidAppeare est terminé et, si je comprends bien, l'application reste inactive pendant un certain temps. Le moteur de test d'interface utilisateur a peut-être déjà créé une arborescence d'éléments d'accessibilité.
Lorsque cette situation se produit et que les appels de code de test tap sur un élément de l’écran principal juste après l’affichage de la vue, les anciens éléments d’accessibilité disparaissent (la hiérarchie des vues a été modifiée à cette époque), mais la méthode tap a été appelée pour un élément avec notamment elementID, etc. qui n'existe pas à cette époque. En conséquence, vous avez un accident.
Il semble que le code d'automatisation soit parfois trop rapide et que, bien que l'instantané de la hiérarchie d'accessibilité contienne votre élément, votre requête passe trop rapidement à l'instruction suivante et le framework n'a pas la possibilité d'agir de manière ciblée ( ) méthode que vous envoyez. J'ai pu minimiser cette erreur en utilisant les fonctions helper de Joe Masilotti pour attendre que les éléments soient d'abord cliquables, puis en ajoutant un sommeil () avant d'appuyer sur l'élément en question ...
J'ai rencontré cela aussi. Dans mon cas, le serveur renvoie plusieurs résultats de requête de recherche de type tête de tête rapidement. L'élément cible apparaît rapidement, mais il n'est pas possible de le scinder systématiquement avant la requête finale. J'ai résolu ce problème en attendant l'existence de l'élément dans la première requête, via XCTWaiter. Puis mettez un sommeil pour englober la durée de tous les résultats de la requête, puis attendez que l'élément soit cliquable. N'utilisez PAS hittable pour le résultat de la première requête car cela échouera car hittable vérifie également si les éléments peuvent être exploités, mais l'interface utilisateur change trop rapidement pour que l'élément puisse être exploité.
Il serait préférable de ne déclencher que la dernière requête à des fins de test ou via la base de code. J'ai également envisagé d'utiliser UIPasteboard pour éviter plusieurs requêtes de frappe de type, mais, autant que je sache, ce n'est pas disponible pour XCTest.
J'ai essayé waitForHittable () à partir de http://masilotti.com/xctest-helpers/ mais dans mon cas, je devais utiliser le sommeil (secondes) avant d'appuyer sur.
De plus, ne pensez pas que les méthodes de Joe Masilotti sont inutiles. Ils sont excellents et j’ai ajouté ceux de l’extension XCTest et de l’extension XCUIElement. C'est juste que waitForHittable () n'a pas fonctionné juste au premier toucher après le chargement de l'écran principal de mon application.