UI Testing con EarlGrey2: Parte 2

¡Hola Hola! Si llegaste hasta aquí porque leíste la primera parte de esta serie de artículos… ¡Genial!. Si no es así, te recomiendo que leas la parte 1 primero. El resto de artículos los puedes encontrar acá:

• Parte 1
• Parte 3

Previously in “UI Testing con EarlGrey2”

En resumidas cuentas, en la primera parte:

• Hablé sobre EarlGrey 1 y sobre el porqué lo elegía para escribir mis pruebas de UI.
• Conté qué es EarlGrey 2 y describí sus componentes principales.
• Hice un paso a paso de como integrar EarlGrey 2 en un proyecto de ejemplo y así tener soporte para pruebas de caja negra.

En esta segunda parte se modificará la aplicación agregando identificadores de accesibilidad para así escribir algunas pruebas de caja negra.

Recuerda que todo lo que se avanzó en la primera parte está en la rama black-box-setup del repositorio que contiene el proyecto de ejemplo.

bastianX6/earlgrey-2-example

¡Comencemos!

Preparando la aplicación

Si hacemos una revisión con Accessibility Inspector a nuestra pantalla principal, nos encontraremos con lo siguiente:

SearchView — Usando (en realidad no) Accessibility Inspector

Básicamente no podemos identificar elemento alguno usando la herramienta. Esto es malo, porque significa que EarlGrey no podrá encontrar elementos con los cuales interactuar. Es necesario ir a las profundidades de las vistas y hacer algunos cambios. En primer término, comenzaré con SearchView .

Agregando identificadores a SearchView

SearchView es la vista que se carga nada más al abrir la aplicación. Su composición se muestra a continuación:

Viendo el código de la vista, podemos a preciar que la variable body posee un elemento VStack que a su vez contiene:

• Una barra de búsqueda representada por la estructura SearchBar
• Un método getView(forState:) en donde los posibles estados se describen en la enumeración SearchViewState

De esta forma para cada estado es posible obtener:

• Un texto con la frase Loading... en el caso .loading
• Un texto con la descripción del error en el caso .error(Error)
• El texto Type an artist or song in search bar en el caso .initial
• Y para el caso .withData es posible obtener una lista de SearchViewCell o un texto indicando que no existen resultados.

Como el contenido de SearchView es dinámico, es necesario poder diferenciar a que corresponde lo que se muestra en pantalla. Para ello he creado una enumeración llamada, SearchViewIdentifiers que se muestra a continuación:

Junto con eso, es necesario aplicar el modificador accessibility(identifier:) a todas las vistas de SearchView y accessibility(label:) a los elementos de la lista, quedando todo finalmente así:

Con estos cambios aplicados, al inspeccionar nuestra vista con Accessibility Inspector podemos apreciar que es posible identificar muchos elementos de la pantalla, a diferencia de lo que sucedía antes:

SearchView — Usando (ahora si) Accessibility Inspector

Agregando identificadores a LookupView

De la misma forma que lo hicimos con SearchView es necesario agregar identificadores de accesibilidad a la vista LookupDetailView, la cual se encarga de mostrar el detalle de lo seleccionado en SearchView .

Como en la recetas de cocina en la televisión, a continuación les presento la preparación terminada y lista para servir:

Viendo el código se puede apreciar como queda LookupDetailView con los identificadores de accesibilidad agregados, todo esto utilizando a la enumeración LookupDetailViewIdentifiers. Revisando con Accessibility Inspector vemos lo siguiente:

LookupDetailView — inspeccionando con Accessbility Inspector

Preparando el target de pruebas de UI

Para poder escribir las primeras pruebas debemos tener en cuenta los algunos aspectos y limitaciones de la herramienta.

En primer lugar, EarlGrey trabaja solamente con teclado virtual y en inglés, por lo que asegúrate de configurar en el simulador lo siguiente:

• Use the same Keyboard Language as macOS desactivado.
• Connect Hardware Keyboard desactivado.
• Borrar cualquier otra distribución de teclado. Para esto en el simulador debes ir a Settings -> General -> Keyboard -> Keyboards y dejar solamente presente los teclados English (US) y Emoji.

Por otra parte, es necesario agregar unos archivos al target ItunesSimpleSearchUITest. Para ello, crea un grupo llamado Utils y agrega en el los siguientes archivos:

• AccessibilityIdentifiers.swift con el contenido de las enumeraciones LookupDetailViewIdentifiers y SearchViewIdentifiers. Esto es necesario para poder identificar los elementos de la vista que se va a probar.
• EarlGrey+NSArray.swift con el siguiente contenido:

Este archivo es necesario debido a un error de EarlGrey que se produce en versiones de iOS 13.4 en adelante.

Nuestra primera prueba

Creando la prueba

Nuestra primera prueba se compone de las siguientes acciones:

• Ingresar texto en la barra de búsqueda.
• Seleccionar el primer elemento de la lista de resultados
• Verificar que todos los elementos de la vista de detalle estén presentes.

Para ello tenemos que crear una nueva prueba de UI en el target ItunesSimpleSearchUITest la cual llamaremos SearchTests:

Agregando nuestra primera prueba

En el archivo SearchTests.swift agrega la siguiente prueba :

Si corremos nuestra prueba, veremos que sucede lo siguiente:

Nuestra prueba— corriendo

La prueba, explicada

Para esta prueba, utilizo la API de interacción de EarlGrey como base, lo que permite realizar cada una de los 3 pasos que fueron expuestos anteriormente. Sin embargo, ¿cómo se ve reflejado cada uno de estos pasos en el código?.

Ingresar texto en la barra de búsqueda

• En primer lugar, para todas las acciones se debe seleccionar el elemento con el que se quiere interactuar. Para ello debes usar EarlGrey.selectElement(with:) el cuál recibe como parámetro un matcher. La lista de todos los matcher y acciones disponibles la puedes encontrar acá.

google/EarlGrey

• Para este caso, debes usar el matcher grey_accessibilityID el cual recibe como parámetro un String con el identificador del elemento. En este caso usamos SearchViewIdentifiers.searchBar.id el cual está asignado para la barra de búsqueda.
• Y en segundo lugar, es necesario ejecutar una acción sobre el elemento. Para esto se debe usar la función perform la cual recibe como parámetro una acción. En este caso la acción a ejecutar es grey_typeText y como parámetro le pasaremos el texto Metallica\n. Es importante que la cadena contenga \n para simular el presionar la tecla intro.

Con esto, la aplicación simula el seleccionar la barra de búsqueda, ingresar por teclado la palabra “Metallica” y presionar buscar, para así ejecutar la búsqueda.

Seleccionar el primer elemento de la lista de resultados

Tal como en el caso anterior, es necesario seleccionar el elemento con el que se desea interactuar. Sin embargo, acá hay algunos cambios que vale la pena tomar en cuenta.

• En primer lugar, además de grey_accessibilityID es necesario utilizar grey_interactable, para asegurarse que se pueda interactuar con el elemento seleccionado.
• Si queremos decirle a EarlGrey que considere la unión de varios matcher en la búsqueda de un elemento se debe usar grey_allOf(). Sin embargo, debido al error que expuse secciones más arriba y que se produce a partir de iOS 13.4 debemos usar uno de los métodos que agregamos en el archivo EarlGrey+NSArray.swift. Por esto en nuestro código veremos:

[grey_accessibilityID(SearchViewIdentifiers.cell.id),
 grey_interactable()].all()

• En segundo lugar, luego de hacer nuestra selección se hace un llamado al método atIndex(0). Esto se debe a que el criterio utilizado anteriormente para seleccionar una celda se cumple para más de un elemento en pantalla. Con esta llamada se le dice a EarlGrey que considere solo el primer elemento que cumpla con la condición de selección.
• Finalmente, es necesario ejecutar un acción con el elemento seleccionado. En este caso la acción presente dentro de perform es grey_tap() , lo que le indica a EarlGrey que debe simular un toque en ese elemento.

Con todas estas instrucciones la aplicación simula el tocar la primera celda de la lista, lo que produce que se presente una nueva vista con el detalle de la celda seleccionada.

Verificar que todos los elementos de la vista de detalle estén presentes.

Llegado este punto, lo que queda es verificar que cada uno de los 4 elementos de la vista de detalle estén presentes en pantalla. Para ello, por cada elemento:

• Se vuelve a usar EarlGrey.selectElement(with:) en conjunto con grey_accessibilityID
• Se llama a función assert , la cual recibe como parámetro un elemento de tipo matcher. En este caso se utiliza grey_sufficientlyVissible() , lo que nos garantiza que el elemento efectivamente está siendo presentando en pantalla.

Con esto finalmente nuestra prueba está completada.

Resumiendo

Con todo lo que se hizo anteriormente, ya estás listo para poder escribir pruebas de caja negra usando EarlGrey. Si quieres ver el proyecto terminado y con todos los avances descritos hasta ahora, puedes revisar la rama black-box-test del proyecto de ejemplo.

bastianX6/earlgrey-2-example

¿Caja blanca?

Si llegaste hasta acá probablemente te estés preguntando ¿Y las pruebas de caja blanca? Debes saber que habilitar el soporte para escribir pruebas de caja blanca involucra hacer pasos muy similares a los descritos en la primera parte, es decir, configurar cabeceras y demases. Por lo mismo, habrá una tercera parte (y espero que final) en donde abordaré ese tema. ¡Estén atentos!