ios - Error de aserción: Error en la prueba de la interfaz de usuario: error al recuperar atributos para el elemento

ios-simulator xcode7

Question

Cuando las pruebas de IU en Xcode (7.2 y 7.3) , mis pruebas fallan a veces con un error bastante genérico:

Error de aserción: Error en la prueba de la interfaz de usuario: error al recuperar atributos para el elemento

.hittable a obtener este error al llamar a .hittable o .tap() en un elemento, pero no puedo decir por qué. He comprobado que todos los elementos con los que estoy tratando tienen su configuración de accesibilidad configurada correctamente y que las vistas de contenedor en las que se encuentran no tienen habilitada la accesibilidad. Por desgracia, esto no parece resolver el problema.

El registro de la consola revela:

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}

Intenté buscar y logré encontrar que ya se había registrado, pero parece que no hay una solución actual ( enlace de radar ) incluso para Xcode 7.3.

Parece que a veces, si reinicio el simulador / dispositivo, este error no ocurre pero esta no es una buena solución.

Answer 1

Intenté waitForHittable () desde http://masilotti.com/xctest-helpers/ pero en mi caso tuve que usar el modo de espera (segundos) antes de hacer tapping.

Además, no creas que los métodos de Joe Masilotti son inútiles. Son geniales y los he agregado en la extensión XCTest y en la extensión XCUIElement. Es solo que waitForHittable () no funcionó solo en el primer toque después de que se cargue la pantalla principal de mi aplicación.

Answer 2

Me encontré con esto también. En mi caso, el servidor está devolviendo múltiples resultados de consulta de búsqueda de cabecera en una sucesión rápida. El elemento de destino aparece rápidamente, pero no se puede golpear de forma constante hasta la consulta final. Resolví esto esperando la existencia del elemento en la primera consulta inicialmente, a través de XCTWaiter. Luego, póngalo en suspensión para abarcar el tiempo de todos los resultados de la consulta y luego espere a que el elemento se pueda golpear. NO use hittable para el primer resultado de la consulta ya que esto fallará porque también puede verificar si se pueden tocar elementos, pero la IU está cambiando demasiado rápido para que se toque el elemento.

Sería mejor si pudiera desencadenar solo la consulta final con fines de prueba o mediante el código base. También consideré el uso de UIPasteboard para evitar las consultas de tipo typeahead, pero, por lo que puedo decir, esto no está disponible para XCTest.

Answer 3

Parece que el código de automatización a veces es demasiado rápido, y aunque la instantánea de la jerarquía de accesibilidad tiene su elemento, su consulta avanza demasiado rápido a la siguiente instrucción y el marco no tiene la oportunidad de actuar con el toque ( ) Método que está enviando. He podido minimizar este error utilizando las funciones de ayuda de Joe Masilotti para esperar a que los elementos puedan ser golpeados primero, y luego agregar un sleep () antes de tocar el elemento en cuestión. Espero que esto ayude.

Answer 4

Puedes usar temporalmente XCUICoordinate.tap() como alternativa. Por ejemplo, reemplace button.tap() con button.coordinateWithNormalizedOffset(CGVector(dx: 0.5, dy: 0.5)).tap() .

Me encontré con el mismo problema, y ​​la solución me funciona.

Answer 5

Tengo este problema Apareció después de una corrección, así que he descubierto qué puede causar esto en mi caso.

En mi aplicación tengo pantalla ''principal''. Su contenido se devuelve desde el servidor y se almacena en caché en el dispositivo. Esta pantalla lleva al usuario a diferentes pantallas ''detalladas''. Cada vez que el usuario regresa de la pantalla detallada, se viewDidAppeare método viewDidAppeare en la pantalla principal. En este método la pantalla principal solicita contenido. Para proporcionar contenido, el ''Administrador de datos'' necesita recuperarlo desde la base de datos o solicitar desde el servidor 2 entidades diferentes en orden estricto para que utilice dispatch_group . La pantalla principal recibe una notificación sobre el nuevo contenido de la llamada dispatch_group_notify , es por eso que es asíncrono. A tiempo, cuando se ejecuta viewDidAppeare , viewDidAppeare se termina y, según tengo entendido, la aplicación queda inactiva por un tiempo reducido. El motor de UI Test podría haber creado ya el árbol de elementos de accesibilidad.

Cuando se produce esta situación y las llamadas de código de prueba tap en algún elemento en la pantalla principal justo después de que apareciera la vista, los elementos de accesibilidad antiguos desaparecen (porque la jerarquía de vistas ha cambiado hasta ese momento), pero se llamó al método de tap para el elemento con elementID elemento en particular, etc. .que no existe hasta ese momento. Como resultado tienes un accidente.