Grabar, reproducir y revisar: Automatización de IU en Xcode

Hola, soy Max. Soy ingeniero del equipo de Xcode. Hay tantas funciones y experiencias increíbles en Xcode que puede resultar abrumador. Por ejemplo, ¿sabías que con un clic puedes ver tu app ejecutarse en docenas de dispositivos, idiomas y configuraciones? Además, podrás obtener un video de alta definición de cada ejecución. Esto es posible gracias a la automatización de IU en Xcode. Veamos cómo funciona. Primero, haré una descripción general de la automatización de la IU. Luego, prepararemos tu app, grabaremos las interacciones como el código de automatización, reproduciremos la automatización en varios dispositivos e idiomas y, finalmente, veremos videos de los resultados y un informe sobre si cada ejecución aprobó o falló.

Comencemos con una descripción general del funcionamiento de la automatización de la IU.

Dentro de Xcode, tenemos dos estructuras de prueba: pruebas Swift y XCTest. Ambas estructuras pueden probar rápido tu app y su código fuente en varias configuraciones.

Al importar XCTest, se incluye automáticamente la estructura XCUIAutomation. XCUIAutomation se puede usar para automatizar tu app y para interactuar con ella como lo hacen las personas. Estas estructuras trabajan juntas para ofrecer un conjunto completo de pruebas de app y, eso es muy bueno. En general, un conjunto completo de pruebas de app incluye pruebas unitarias y de automatización de IU. Las pruebas unitarias revisan la lógica y los modelos de tu app. Con las pruebas Swift, es posible ejecutar pruebas en estructuras y paquetes Swift que no tienen IU. Mientras, las pruebas de automatización de la IU validan la experiencia del usuario de tu app, la integración con el hardware de Apple y el comportamiento de los flujos de trabajo comunes.

En general, tu conjunto de pruebas tendrá más pruebas unitarias que pruebas de IU y tú querrás lograr una cobertura completa del código. Pero las pruebas de automatización de la IU te permiten ver cómo se ve, comporta e integra tu app con el resto del sistema operativo. Esto tiene muchos beneficios.

Por ejemplo, puedes probar tu app con gestos, como toques, deslizamientos y clics, como si fuera una persona. Puedes comprender cómo perciben tu app quienes usan tecnologías de asistencia, como VoiceOver, Voice Control y Dynamic Type.

Puedes ver tu app ejecutarse en todos los idiomas y regiones que admite, y centrarse en los idiomas que muestran efectos más largos como los idiomas con cadenas largas o con diseño de derecha a izquierda. Puedes probar la integración de tu app con las funciones de hardware de Apple, como el Botón de Acción, el de la cámara, el Apple TV Remote y la Digital Crown del Apple Watch. Por último, puedes probar el rendimiento del lanzamiento de tu app: una métrica clave para saber qué tan rápido se puede comenzar a usar tu app. Para configurar un flujo de trabajo de automatización de IU, hay tres fases clave: grabar, reproducir y revisar.

Primero, graba tus interacciones, como toques, deslizamientos y pulsaciones de botones de hardware, luego observa cómo Xcode las escribe automáticamente como código. Reproduce tus interacciones en múltiples dispositivos, idiomas, regiones y orientaciones, en tus dispositivos y en Xcode Cloud. Por último, revisa los videos y resultados de la ejecución de tu app en todas esas configuraciones y observa las que funcionaron y las que no. La automatización de la IU es compatible con todas las plataformas de Apple: iOS, iPadOS, macOS, watchOS, tvOS y visionOS (diseñado para iPad). La misma automatización puede ejecutarse en múltiples plataformas. Así puedes crear una automatización una vez y ejecutarla en todos los dispositivos compatibles. Esto significa que puedes ver cómo funciona tu app en Mac, iPhone y Vision Pro con un clic y sin cambios de código. Veamos brevemente cómo funciona la automatización de la IU. La automatización de la IU interactúa con tu app como una persona con gestos y eventos de hardware. La automatización se ejecuta independientemente de tu app, por lo que los modelos y datos de tu app no están accesibles directamente.

La automatización de la IU le dice al sistema operativo qué gestos realizar y espera sincrónicamente a que se completen uno a la vez.

Esto es iniciar la app, interactuar con los botones y la navegación, configurar el estado del sistema, como Modo Oscuro, y hasta configurar una ubicación simulada para el dispositivo. En Apple, la accesibilidad es uno de nuestros valores fundamentales. Las tecnologías de asistencia de Apple garantizan el uso de tu app independientemente de cualquier discapacidad física, visual, auditiva o motriz. Trabajamos mucho para garantizar que la mayoría de estas tecnologías funcionen con tu app de forma predeterminada, sin que trabajes en ello como desarrollador. Pero, si agregas soporte adicional, puedes enriquecer la experiencia de tu app y hacer que sea aún más fácil de automatizar. La cuestión es que la accesibilidad es la estructura subyacente que impulsa la automatización de la IU. Una excelente experiencia de accesibilidad significa que también tendrás una excelente experiencia de automatización de IU. La accesibilidad brinda datos directo a la automatización de la IU, pero lo que ve la accesibilidad no es idéntico a lo que ve una persona. Veamos un ejemplo. Aquí el botón Great Barrier Reef es visible en la IU, pero la accesibilidad ve más que eso. La accesibilidad puede ver el tipo y la etiqueta de los elementos, y mostrarlos a la automatización de la IU, pero también puede mostrar la propiedad del identificador. Con el identificador de accesibilidad se puede describir cualquier elemento de la pantalla en particular, en relación con todos los elementos que lo rodean. No necesitas localizar el identificador, por lo que puedes usarlo para hacer referencia a un elemento de la IU en cualquier idioma o dispositivo.

Para casillas de verificación y elementos con estado, puedes usar una propiedad de valor. Esto muestra el estado actual del elemento para la accesibilidad y para la automatización de la IU.

Puedes obtener información en “Build accessible apps with SwiftUI and UIKit” de la WWDC23 o en “SwiftUI Accessibility: Beyond the basics” de la WWDC21.

Ya vimos el funcionamiento de una automatización de IU con accesibilidad, ahora preparemos la automatización de tu app.

Primero, agregaremos identificadores de accesibilidad. Luego, haremos una breve revisión de la accesibilidad de tu app. Por último, agregaremos un nuevo objetivo de prueba de IU para prepararnos para registrar nuestras interacciones como código. Antes de continuar, vale la pena señalar que tu app ya es compatible con la automatización de IU y la grabación de IU, sin que trabajes en ello como desarrollador. Los pasos que vamos a cubrir no son obligatorios, pero pueden conducir a resultados mejores y de mayor calidad. Se pueden agregar identificadores de accesibilidad en el código de vista escrito en SwiftUI, UIKit o AppKit. Los identificadores de accesibilidad son la mejor manera de identificar cualquier elemento de tu app para la automatización. Es ideal agregar identificadores de accesibilidad a elementos con cadenas localizadas o contenido dinámico. Esto es, contenido de tus modelos de datos o que se descarga de Internet.

Los buenos identificadores son únicos dentro de la app, detallan el elemento en el que están y son estáticos, no reaccionan a los cambios en el contenido.

Si bien los títulos y las descripciones pueden cambiar, los identificadores correctos siempre describen el contenido del elemento al que están asociados. Así, nos aseguramos de que “Max's Lovely Landmarks” quedará fijo allí.

En SwiftUI, puedes agregar el modificador accessibilityIdentifier a cualquier elemento de la IU. Se reconocerá si tu vista y la matriz no están ocultas a la accesibilidad.

Es ideal que los identificadores sean específicos para una instancia de una vista, especialmente para las vistas que se usan varias veces en tu app. Aquí, usamos la propiedad landmark.id para hacer que el identificador sea único para cada uno.

En UIKit, se puede configurar la propiedad accessibilityIdentifier en cualquier UIView si la vista es un elemento de accesibilidad. La mayoría de las vistas de la IU, como los controles, el texto y las imágenes, son elementos de accesibilidad predeterminados, por lo que no es necesario realizar ninguna tarea adicional.

Propiedades como accessibilityLabel, accessibilityTraits y accessibilityValue son útiles para tecnologías de asistencia como VoiceOver y también para la automatización de la IU.

Aún así, VoiceOver no lee en voz alta la propiedad accessibilityIdentifier y no queda expuesta a ninguna persona que use la app. Así resulta una buena forma de informar aquello útil solo para la automatización, como el índice de una celda de una tabla o el nombre del símbolo de una imagen. Incluso puedo hacer que el asistente de codificación en Xcode agregue identificadores de accesibilidad para mí. Por ejemplo, puedo escribir: “Agregar identificadores de accesibilidad a las partes relevantes de la vista”, y ocurrirá. El asistente de codificación sabe cómo utilizar la propiedad id en un punto de interés para hacer que cada identificador sea completamente único. Excelente. Revisar el comportamiento de accesibilidad general de tu app es una buena idea antes de grabar la IU. Es como usar hilo dental antes del dentista. Sabrás exactamente qué tan bien lo hiciste enseguida. Esto solo te dará una buena vista previa. Xcode viene con la app Accessibility Inspector: te permite encontrar, diagnosticar y solucionar problemas de accesibilidad. Inspector se inicia desde el menú de nivel superior de Xcode en Abrir herramienta para desarrolladores. También se puede iniciar desde Spotlight.

Accessibility Inspector puede enumerar los valores de accesibilidad para cualquier vista de tu app en cualquier plataforma. Selecciona la plataforma que deseas inspeccionar, haz clic en el elemento Inspector e interactúa con el elemento de la IU que deseas conocer en esa plataforma. Se mostrará una lista de propiedades del elemento. Algunos, como los de la sección Básica, son realmente útiles para la automatización de la IU. Para las vistas sin información, es posible que desees cambiar el código fuente de tu app y agregar algo. Encuentra detalles sobre cada propiedad haciendo clic en el nombre de una propiedad. La ventana emergente te dirá qué propiedad establecer, te ofrecerá documentación al respecto y más.

Puedes aprender aún más sobre las funciones de accesibilidad con nuestro proyecto de código de ejemplo, “Delivering an exceptional accessibility experience”. Este proyecto proporciona excelentes ejemplos de código para una app que utiliza numerosas funciones de accesibilidad y es muy fácil de usar para la automatización de la IU. También puedes consultar el artículo “Performing accessibility testing for your app” para conocer formas de comprobar la accesibilidad de tu app con diferentes tecnologías de asistencia. Cuando estemos listos para comenzar a automatizar, debemos agregar un nuevo objetivo de prueba de IU para tener un lugar donde colocar nuestro código de automatización.

En la vista de configuración del proyecto en Xcode, agrega un nuevo objetivo con el botón “+” debajo de la lista de objetivos.

Luego, selecciona UI Testing Bundle en la ventana emergente.

Al hacer clic en Finish, se agregará una carpeta y una plantilla de prueba de IU a tu proyecto. La plantilla tiene pruebas simples que te ayudarán a comenzar. Estamos listos para grabar mágicamente todas nuestras interacciones como código Swift. Usemos el simulador de iOS y Xcode para esto. Hace un tiempo, mi madre se fue un mes a Australia y me apena no haber podido ir. Por suerte, hay una app para eso. Puedo usar el proyecto de muestra Landmarks de la WWDC de este año para planificar mis vacaciones. Registraré algunas interacciones que planifiquen mi viaje para asegurarme de que el flujo de trabajo no se interrumpa en futuras versiones de la app. Cuando abra el archivo fuente de prueba de IU por primera vez, aparecerá una ventana emergente que me indicará cómo puedo iniciar una grabación de IU. Luego, iniciaré una grabación de IU con el botón en la barra lateral, y Xcode compilará y relanzará automáticamente mi app en Simulator.

Una vez que inicié mi app, iré a la vista de colecciones.

A medida que interactúo con la app, el código de mis interacciones se graba en el editor de origen. Iré al botón “+” para agregar una colección y comenzar a planificar mi viaje a Australia. Ahora tocaré el botón Edit para cambiar el nombre del viaje, y le pondré el nombre “Max’s Australian Adventure”.

Xcode mantendrá mi prueba actualizada mientras escribo.

Ahora editaré la colección de puntos de interés.

Agrego algunos puntos de referencia australianos como la Gran Barrera de Coral y Uluru, y toco la marca de verificación.

Cuando regreso a la vista de colecciones, puedo ver que se agregó mi colección con algunos puntos de referencia australianos incluidos.

Puedes detener la grabación de la IU con el botón de detener en Xcode. Cuando finalices la grabación, puedes hacer algunas cosas para asegurarte de obtener la automatización que deseabas. Primero, revisa el código grabado. Luego, agrega validaciones con las API de XCTest para garantizar que tu app funcione como esperas. Por último, explora otras API de automatización que pueden hacer que tu prueba sea aún más potente.

Revisemos las consultas de IU que se registraron y veamos si hago algún ajuste. Cada línea de código grabado tendrá múltiples opciones para abordar cada elemento de la IU, y la que elijas dependerá de tus objetivos. Puedes hacer clic en el menú desplegable en cada línea del código fuente para ver las opciones.

Un consejo: elegir la opción correcta te ayudará a abordar tu avión a Australia más rápido.

Algunas recomendaciones para ayudarte con la elección:

para las vistas que tienen cadenas localizadas, como elementos de texto o botones, recomendamos elegir un identificador de accesibilidad si hay uno. La grabación de IU intenta usar el identificador predeterminado si existe uno.

Para las vistas que están muy anidadas, como el texto en las vistas de desplazamiento, recomendamos elegir la consulta más corta. Esto ayudará a que la automatización siga resistente a medida que tu app cambia.

Por último, para el contenido dinámico que se descarga de Internet o el contenido que cambia con frecuencia, como las marcas de tiempo o la temperatura, recomendamos una consulta más genérica o un identificador de accesibilidad si existe uno.

Aquí, no usamos un identificador ni ninguna cadena, solo hacemos referencia al primer fragmento de texto.

Llegó el momento de decidir. Haré clic en la línea del código fuente que quiero editar para ver las opciones. Todas estas consultas identifican de forma única el elemento de la interacción, por lo que realmente no hay ninguna elección incorrecta. Solo se trata de elegir cómo deseas almacenar una referencia a esta parte de la IU para el futuro. Seleccionaré la opción textFields.firstMatch para asegurarme de que el campo de texto siempre esté seleccionado en mi prueba sin importar cómo se llame. Haré doble clic en cualquiera de los menús desplegables para almacenar este resultado en su código fuente. Ahora ejecutemos rápido mi automatización nuevamente para ver si registró bien mis acciones. Haré clic en el diamante de prueba para ejecutarlo. Estamos probando tu app, no queremos probar tu paciencia. Con gran rapidez, se ejecuta la repetición de la automatización.

La colección se crea rápidamente con el nombre correcto, se agregan las ubicaciones y se realiza la automatización. ¡Increíble! Eso fue mucho más rápido que un vuelo de 19 horas. Ahora agregaremos validaciones al código para comprobar el comportamiento esperado. Aquí, validaré que el punto de interés Great Barrier se haya agregado a mi colección.

Puedo llamar a métodos waitForExistence para que mi automatización espere a que aparezca un elemento antes de continuar. También puedo llamar al método de una forma más genérica, wait(for:toEqual:) para validar que cualquier propiedad en un XCUIElement coincida con el resultado esperado.

Puedo combinar ambos métodos con declaraciones XCTAssert de XCTest para que falle la prueba si estos métodos devuelven falso.

Ahora, volveré a mi código y agregaré un waitForExistence en el nombre de mi colección para asegurarme de que siempre esté allí en futuras ejecuciones.

Este es un buen momento para explorar otras API de automatización para hacer que el código sea aún más potente.

Resulta útil usar el método de instancia de configuración de un XCTestCase para asegurarse de que el dispositivo esté en el mismo estado en futuras ejecuciones. Puedo usar API como Orientation, Appearance, o incluso simular una ubicación para que mi dispositivo esté en el estado correcto antes de que comience una ejecución.

Antes de iniciar mi app, puedo usar propiedades como launchArguments y launchEnvironment para que mi app use esos parámetros cuando se solicita el método de inicio.

Si tu app admite un esquema de URL personalizado, puedes abrirla en una URL coincidente directamente con el método de apertura XCUIApplication.

Incluso hay una versión global, que abre una URL con la app predeterminada del dispositivo.

Por último, es posible realizar una prueba de accesibilidad de tu app dentro de una prueba de IU. Una excelente sesión sobre eso es “Perform accessibility audits for your app” de la WWDC23. Ahora que grabamos nuestras interacciones y configuramos la automatización, configuremos las pruebas para que se reproduzcan en múltiples configuraciones, en el escritorio y en la nube. Es muy útil agregar tu prueba a un plan de prueba nuevo o existente. Los planes de pruebas te permiten incluir o excluir pruebas individuales, establecer configuraciones del sistema sobre dónde y cómo se ejecutan las pruebas y administrar propiedades de pruebas como tiempos de espera, repeticiones, paralelización, orden de ejecución y más.

Los planes de prueba también están asociados a un esquema, que te permiten combinar un plan de prueba con configuraciones de compilación específicas.

Encontrarás más información en el artículo “Improving code assessment by organizing tests into test plans” en nuestra documentación para desarrolladores.

En tu plan de pruebas, puedes agregar o eliminar pruebas en la primera pantalla o cambiar a la pestaña Configurations para realizar cambios en cómo se ejecutará la prueba. Puedo configurar varias configuraciones para ejecutar mi app en varios idiomas.

En general, cada configuración regional existe como una configuración independiente en tu plan de prueba.

Puedes tener configuraciones enfocadas en una configuración regional específica u otras configuraciones compartidas entre ellas.

Puede ser útil incluir configuraciones para idiomas con cadenas más largas, como el alemán, o idiomas de derecha a izquierda, como el árabe y el hebreo.

Incluso hay configuraciones enfocadas en la automatización de la IU en la pestaña Configurations.

Algunas son: si se grabará un video o capturas de pantalla durante la ejecución y si se conservará algún contenido luego.

De forma predeterminada, los videos y las capturas de pantalla solo se guardan en las ejecuciones fallidas, para que puedas revisar cualquier problema. Si deseas conservarlos para todas las ejecuciones, incluso las aprobadas, selecciona “On, and keep all”. Esta configuración te permitirá conservar grabaciones para otros fines, como documentación, tutoriales o marketing. Hay muchas otras configuraciones excelentes para explorar en la pestaña Configurations. Puedes consultar “Author fast and reliable tests for Xcode Cloud” de la WWDC22 para más información.

Xcode Cloud es un servicio integrado en Xcode, también está disponible en App Store Connect. Te puede ayudar a crear tu app, ejecutar pruebas, cargarlas en el App Store y mucho más. Todo esto sucede en la nube sin usar tus dispositivos ni los de tu equipo. Descubrirás que cuando se trata de Xcode Cloud, todo es pura diversión. Para la app Landmarks, configuramos un flujo de trabajo de Xcode Cloud que ejecuta todas las automatizaciones de IU que escribí, y usa el plan de prueba que creé. Este plan se ejecutará en la nube como se ejecutó en mi simulador, en cualquier cantidad de dispositivos y configuraciones como inglés, árabe, hebreo y alemán en iPhone y iPad.

Puedes ver un historial de tus ejecuciones de Xcode Cloud desde Xcode o en la sección Xcode Cloud de App Store Connect. Allí podrás ver una descripción general de la información de creación, registros, descripciones de fallas y mucho más.

Con Xcode Cloud, todo mi equipo puede ver un historial de mis ejecuciones y descargar los resultados y grabaciones de video. Pueden hacerlo incluso si estoy en las nubes, y con esto me refiero a en mi vuelo a Sídney.

Hay mucho más que aprender sobre Xcode Cloud. Para configuraciones más avanzadas, consulta “Create practical workflows in Xcode Cloud” de la WWDC23. Ejecutamos nuestras pruebas grabadas con un plan de prueba en múltiples configuraciones, ahora podemos revisar los resultados y las grabaciones de video usando el informe de prueba. El informe de pruebas de Xcode tiene algunas herramientas excelentes para ayudarte a ver, comprender y diagnosticar los resultados de tus pruebas. Parece que una de nuestras ejecuciones falló desde la automatización que recién ejecuté. Creo que todavía no puedo hacer las maletas para ir a Australia. Para navegar hasta mi prueba fallida, haré clic en el botón Test, luego haré doble clic en la ejecución fallida para ver una grabación de video y una descripción de lo que ocurrió.

Puedo ver las ejecuciones de esta prueba en el menú desplegable de las ejecuciones. Esto me permite cambiar rápido entre grabaciones de video de mi prueba que se ejecutan en diferentes configuraciones, como en diferentes idiomas. Además, un dato curioso es que puedo descargar el video haciendo clic con el botón derecho y, luego, en Save Video.

Presionaré Play para iniciar la reproducción.

A medida que se reproduce el video, se superponen puntos que muestran interacciones de la IU sobre el video. Estas acciones también aparecen en la línea de tiempo con puntos debajo.

Al parecer el error está más adelante, así que continuemos. Saltaré directo al momento del error con el diamante de error en la línea de tiempo.

Veo un mensaje de error, pero es difícil decir qué salió mal. El mensaje dice que busca el botón llamado Max’s Australian Adventure. Veamos qué había en realidad en el punto de error.

Allí, veo una superposición de todos los elementos de la IU que estaban presentes justo encima de la grabación de video.

Si hago clic en cualquiera de estas, aparecen recomendaciones de código sobre cómo puedo abordar este elemento en mi código de automatización. Incluso puedo presionar Show All para ver ejemplos alternativos y encontrar uno que funcione para mí. Creo que veo lo que está mal. Esperábamos que hubiera un botón, pero aquí no hay ningún botón. Es solo texto. Arreglaré esto muy rápido.

Seleccionaré la muestra que quiero y haré clic secundario para copiarla.

Luego, puedo hacer clic en View Source para ir directamente a mis pruebas y pegar la nueva línea de código sobre la existente.

Ahora, puedo reemplazar la variable temporal XCUIApplication con la variable de la app para mi grabación de IU y listo.

Ahora debería funcionar como esperaba. Haré clic en el diamante de prueba para ver la repetición de la prueba. Esta vez, ejecutaré la prueba en árabe para ver que la misma automatización funciona incluso cuando mi app se ejecuta en un diseño de derecha a izquierda.

La automatización crea rápidamente mi colección y la renombra tal como lo hace en inglés. Excelente.

Parece que la automatización funcionó. Es hora de terminar esto y emprender el viaje de mi vida. Quizás mi mamá pueda acompañarme para mostrarme los hermosos paisajes. Podemos hacer mucho más con el informe de pruebas de Xcode. Por suerte, la sesión “Fix failures faster with Xcode test reports” de la WWDC23 realmente profundiza el tema. Es increíble cómo la automatización de la IU, la accesibilidad, la localización, Xcode Cloud y el informe de pruebas trabajan juntos para aumentar la calidad de tu app y facilitar su uso para todas las personas del mundo. Unir estas tecnologías en un único flujo fue una gran alegría y estoy ansioso por ver cómo lo usan los desarrolladores.

Puedes obtener más información sobre pruebas unitarias y pruebas Swift en la charla “Meet Swift Testing” de la WWDC24. Si tienes dudas o comentarios adicionales, puedes encontrarnos en Developer Forums. Gracias por estar ahí y nos vemos en Australia.