[REPRODUCCIÓN DE MÚSICA] Escribir buenos exámenes
puede ser un desafío. Y escribir pruebas de UI confiables
es sustancialmente más difícil. Las interfaces de usuario
son asincrónicas y están impulsadas por eventos,
transiciones y datos cargados desde subprocesos en segundo plano. Codificar en torno a esto sin la
ayuda de un marco de prueba de UI requeriría una gran cantidad
de textos repetitivos y manejo de casos extremos. Por otro lado, supongamos que le doy
un teléfono con una aplicación de muestra y le digo que pruebe
una función de la aplicación que acabo de implementar. Por ejemplo, asegúrese de
que funcione guardar una nueva nota en mi aplicación para tomar notas. ¿ Qué harías? Bueno, estoy bastante seguro de que
buscarías un botón Guardar.
Una vez que la haya encontrado
, la tocará y luego verificará si la nota
está presente en la lista de notas guardadas. En realidad, ese es un
escenario bastante bueno para una prueba de interfaz de usuario y es fácil de
entender para una persona. Pero, ¿cómo haríamos para
expresarlo en código? El marco Espresso
se creó específicamente para este propósito:
permitir a los desarrolladores escribir pruebas de interfaz de usuario que sean
concisas, confiables y que utilicen una API fluida. Y lo más importante, Espresso
se encarga de la sincronización con cualquier evento de la interfaz de usuario para
que, en la mayoría de los casos, no tenga que preocuparse por las
transiciones de estado de vista ni los detalles de implementación. Mirando hacia atrás en la
prueba de interfaz de usuario simple que acabamos de definir, podemos ver que el
flujo básico cuando se usa Espresso es exactamente el mismo que en
nuestro escenario de la vida real.
Primero, busque una vista usando
algunas reglas de coincidencia. Luego realiza una acción sobre él. Y finalmente, verificar
el estado resultante. Antes de continuar y
comenzar a escribir código de prueba real, asegurémonos de que
el ejecutor de pruebas de Android y las dependencias de Espresso
estén configurados en build.gradle. Agregaré las dependencias
y configuraré el corredor aquí. Si está utilizando una versión
de Android Studio que le permite seleccionar
el artefacto de prueba, recuerde cambiar a la prueba de
instrumentación de Android en Variantes de compilación. Estoy usando Android
Studio 2.0, que tiene una vista combinada para pruebas
locales y de instrumentación . Entonces ya puedo ver
ambos en la vista de mi proyecto. Las pruebas de instrumentación se incluyen en
el conjunto de fuentes de prueba de Android.
Así que crearé una
clase de prueba de muestra aquí y la llamaré NotesScreenTest. Tengo que agregar una anotación
en la clase de prueba para especificar que escribiré
pruebas de Junit 4 y las ejecutaré con el
ejecutor de Android Junit 4. La pantalla de notas en
nuestra aplicación está contenida en la actividad de notas. Al agregar una
regla de prueba de actividad, le digo al corredor que inicie
la actividad antes de cualquier prueba y que la rechace
una vez que termine. Todo esto se
soluciona con esta línea. Ahora agregaré un nuevo
método con un nombre descriptivo para la prueba real y
comenzaré con la estructura básica que expliqué antes. Tenga en cuenta que onView es en realidad
un método de la clase Espresso. Pero en mi código de prueba,
usaré importaciones estáticas para poder expresar las
pruebas de una manera más concisa.
Está bien. Repasemos
los argumentos a continuación. Necesitamos un comparador para
encontrar una vista en la jerarquía de vistas actual . Espresso viene con un
conjunto de comparadores integrados para propiedades de vista comunes
como Con ID, Con texto, Está marcado y muchas otras. Proporcionamos una
hoja de referencia sencilla para que no tenga que buscar en
la documentación cada vez. En mi caso, quiero ubicar el
botón de acción flotante, que afortunadamente es el único elemento
en la pantalla con el ID fab_add_notes. Ahora que he aislado la vista
que necesito usando comparadores, es hora de aplicar
una acción de vista o, en otras palabras,
una interacción de usuario que será
simulada por Espresso. Solo quiero hacer clic en FAB. Pero nuevamente, hay muchas más
acciones integradas, como escribir e incluso deslizar el dedo, que
puedo usar para interactuar con las vistas. Y finalmente, verifico
el resultado de mis acciones mediante una aserción de vista. Como quiero verificar si se
muestra un campo de entrada en la pantalla después de
presionar el fab, moveré este
bloque de código aquí.
Y uso la aserción de coincidencias
que acepta un comparador de vistas. Entonces, para resumir
lo que tenemos hasta ahora, la primera declaración coincide con
un botón de acción flotante y hace clic en él, lo que debería
abrir la pantalla Agregar nota. La segunda declaración
encuentra el texto de edición que permite al usuario
ingresar el título de una nota y verifica que se
muestre mediante la aserción de vista de coincidencias. Tenga en cuenta que no tuve que
escribir ningún código en el medio para esperar a que finalizaran los eventos anteriores
, ya que Espresso ya se encarga
de eso por mí. Para ejecutar la prueba, hago
clic derecho en la clase de prueba y selecciono Ejecutar. Al ser una
prueba de instrumentación, requiere un emulador
o dispositivo físico.
Puedo ver las acciones en
la pantalla mientras se ejecutan. Aquí hay una
prueba un poco más larga que incluye escribir en la
pantalla para agregar notas y guardar una nota, todo usando Espresso. A menos que esté escribiendo
pruebas de un extremo a otro, debe mantenerlas
pequeñas y con un alcance limitado, lo que las hará más confiables. Si desea practicar cómo
agregar y ejecutar pruebas de UI por su cuenta, le
sugiero que consulte nuestro Codelab de pruebas de Android, en
el que basé este video. Contiene un
proyecto descargable e instrucciones paso a paso
para comenzar. Únase a mí en el próximo
episodio de Patrones de prueba de Android para aprender cómo manejar las
vistas del adaptador en sus pruebas.
Buena suerte y felices pruebas. [REPRODUCCIÓN DE MÚSICA].