Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Android SDK
Code

Pruebas de Interfaces de Usuario de Android con Espresso

by
Difficulty:IntermediateLength:LongLanguages:

Spanish (Español) translation by Alfonso Mora (you can also view the original English article)

En este post, usted aprenderá acerca de cómo escribir pruebas de IU con el marco de prueba de Espresso y automatizar su flujo de trabajo de prueba, en lugar de utilizar el proceso tedioso y propenso a error manual.

Espresso es un marco de pruebas para escribir pruebas de interfaz de usuario en Android. Según la documentación oficial, usted puede:

Pruebas de uso expreso escritura concisa, hermoso y confiable Android UI.

1. ¿Por qué Utilizar Espresso?

Uno de los problemas con la prueba manual es que puede ser largo y tedioso de realizar. Por ejemplo, para probar una pantalla de inicio de sesión (manualmente) en una aplicación Android, deberás hacer lo siguiente:

  1. Lanzar la aplicación.
  2. Desplácese a la pantalla de inicio de sesión.
  3. Confirmar si los usernameEditText y passwordEditText son visibles.
  4. Escriba el nombre de usuario y contraseña en sus respectivos campos.
  5. Confirmar si el botón de inicio de sesión también es visible y luego haga clic en el botón de inicio de sesión.
  6. Comprobar si los puntos de vista correctos aparecen cuando ese login fue exitoso o fue un fracaso.

En lugar de pasar todo este tiempo nuestra aplicación de prueba manualmente, sería mejor dedicar más tiempo a escribir código que hace que nuestra aplicación se destacan del resto! Y aunque la prueba manual es tedioso y muy lento, es aún propensa a errores y usted podría pasar por alto algunos casos de la esquina.

Algunas de las ventajas de las pruebas automatizadas incluyen los siguientes:

  • Pruebas automatizadas ejecutan exactamente los mismos casos de prueba cada vez se ejecutan.
  • Los desarrolladores rápidamente pueden detectar un problema rápidamente antes de enviarlo al equipo de QA.
  • Se puede ahorrar mucho tiempo, a diferencia de hacer pruebas manuales. Por ahorro de tiempo, ingenieros de software y el equipo de control de calidad en lugar de otro pasar más tiempo en tareas desafiantes y gratificantes.
  • Se logra mayor cobertura de la prueba, que conduce a una mejor aplicación de la calidad.

En este tutorial, aprenderemos acerca de café mediante la integración en un proyecto de estudio Android. A escribir pruebas de interfaz de usuario para una pantalla de inicio de sesión y un RecyclerView, y aprenderemos acerca de las intenciones de pruebas.

La calidad no es un acto, es un hábito. — Pablo Picasso

2. Requisitos Previos

Para poder seguir este tutorial, necesitará:

Un proyecto de muestra (en Kotlin) para este tutorial se puede encontrar en nuestro repositorio de GitHub para que pueda seguir fácilmente a lo largo.

3. Crear un Proyecto Android Studio

Ejecuto su Android 3 Studio y cree un nuevo proyecto con una actividad vacía llamada MainActivity. Asegúrese de comprobar Kotlin Incluyen Soporte.

Create Android Project dialog

4. Configurar Espresso y AndroidJUnitRunner

Después de crear un nuevo proyecto, asegúrese de agregar las siguientes dependencias de la biblioteca de soporte de prueba Android en tu build.gradle (aunque estudio Android ya ha incluido para nosotros). En este tutorial, utilizamos el café última versión 3.0.2 de la biblioteca (a partir de este escrito).

Se incluyeron también el corredor de instrumentación AndroidJUnitRunner:

Una Instrumentación que va JUnit3 y JUnit4 pruebas contra un paquete de Android (aplicación).

Tenga en cuenta que la Instrumentación es simplemente una clase base para la implementación de código de aplicación de la instrumentación.

Desactivar Animación

La sincronización de Espresso, que no sabe esperar para que una animación hasta el final, puede hacer algunas pruebas para fallar, si se permite la animación en el dispositivo de prueba. Para desactivar animación en el dispositivo de prueba, vaya a Configuración > Opciones de Desarrollador y apagar todas las opciones siguientes en la sección "Dibujo":

  • Escala de animación de ventana
  • Escala de animación de transición
  • Escala de duración de animador

5. Escriba Su Primera Prueba en Espresso

En primer lugar, empezamos pruebas una pantalla de inicio de sesión. Aquí es cómo comienza el flujo de inicio de sesión: el usuario inicia la aplicación, y la primera pantalla que aparece contiene un solo botón de Inicio de sesión. Cuando se hace clic en el botón de Inicio de sesión, abre la pantalla de LoginActivity. Esta pantalla contiene dos EditTexts (los campos nombre de usuario y contraseña) y un botón Enviar.

Esto es lo que nuestro MainActivity diseño parece:

MainActivity layout

Aquí está lo que nuestros LoginActivity diseño parece:

Vamos a escribir ahora una prueba para nuestra clase MainActivity. Ir a la clase MainActivity, mueva el cursor hasta el nombre MainActivity y presione Shift-Control-T. Seleccione Crea Nueva Prueba... en el menú emergente.

Create new test dialog

Presione el botón Aceptar y aparece otro cuadro de diálogo. Elija el directorio androidTest y haga clic en el botón Aceptar una vez más. Tenga en cuenta que ya estamos escribiendo una prueba de instrumentación (pruebas específicas del SDK de Android), los casos de prueba residen en la carpeta androidTest/java.

Ahora, Android Studio ha creado con éxito una clase de prueba para nosotros. Sobre el nombre de clase, incluya esta anotación: @RunWith(AndroidJUnit4::class).

Esta anotación significa que todas las pruebas de esta clase son las pruebas específicas de Android.

Pruebas de Actividades

Porque queremos probar una actividad, tenemos que hacer una pequeña configuración. Tenemos que informar a exprés que actividad para abrir o ejecutar antes de ejecutar y destruir después de la ejecución de cualquier método de prueba.

Tenga en cuenta que la anotación de @Rule significa que se trata de una regla de prueba JUnit4. Las reglas de prueba JUnit4 se ejecutan antes y después de cada prueba método (con @Test). En nuestro propio escenario, queremos lanzar MainActivity antes de cada método de prueba y después destruir.

También incluimos la @JvmField anotación de Kotlin. Esto simplemente indica al compilador que no para generar captadores y definidores de la propiedad y en su lugar para exponer como un campo simple de Java.

Aquí están los tres pasos principales por escrito una prueba de Espresso:

  • Aspecto del widget (TextView o Button) que desea probar.
  • Realizar una o más acciones de ese widget.
  • Verificar o comprobar si ese widget está ahora en un determinado Estado.

Los siguientes tipos de anotaciones pueden aplicarse a los métodos utilizados dentro de la clase de prueba.

  • @BeforeClass: Esto indica que debe ser ejecutado el método estático esta anotación se aplica a una vez y antes de todas las pruebas en la clase. Esto se podría utilizar, por ejemplo, para configurar una conexión a una base de datos.
  • @Before: indica que el método esta anotación se une a debe ser ejecutado antes de cada método de prueba en la clase.
  • @Test: indica que el método esta anotación se une a debe funcionar como un caso de prueba.
  • @After: indica que debe ejecutar el método de esta anotación se une a después de cada método de prueba.
  • @AfterClass: indica que el método esta anotación se une a debe ejecutar después de que se han ejecutado todos los métodos de prueba en la clase. Aquí, típicamente cerca recursos que fueron abiertos en @BeforeClass.

Encontrar una View Utilizando onView()

En nuestro archivo de diseño MainActivity, sólo tenemos un widget, el botón de Inicio de sesión. Vamos a probar un escenario donde un usuario encontrar ese botón y haga clic en él.

Para buscar widgets en Espresso, hacemos uso del método onView() estático (en lugar de findViewById()). El tipo de parámetro que suministramos a onView() es un Matcher. Tenga en cuenta que la API Matcher no viene desde el SDK de Android sino de proyecto Hamcrest. Biblioteca de matcher de Hamcrest es dentro de la biblioteca de Espresso que tiró a través de Gradle.

El onView(withId(R.id.btn_login)) vuelve a ViewInteraction que es para una View cuyo ID es R.id.btn_login. En el ejemplo anterior, utilizamos withId() para buscar un widget con un id determinado. Otros dispositivos de comparación de vista que podemos utilizar son:

  • withText(): devuelve un matcher que coincide con el TextView basándose en su valor de la propiedad de texto.
  • withHint(): devuelve un matcher que coincide con el TextView basándose en el valor de la propiedad de su sugerencia.
  • withTagKey(): devuelve un matcher que coincide con el View basándose en las claves de la etiqueta.
  • withTagValue(): devuelve un matcher que coincide con View basándose en los valores de las propiedades de etiqueta.

En primer lugar, vamos a probar para ver si el botón se muestra realmente en la pantalla.

Aquí, sólo estamos confirmando si el botón con el identificador dado (R.id.btn_login) es visible para el usuario, así que usamos el método check() para confirmar si View subyacente tiene un determinado Estado, en nuestro caso, si está visible.

El método estático matches() devuelve un ViewAssertion genérico que afirma que una visión existe en la jerarquía de la vista y es comparable con el matcher de vista. Matcher vista es devuelto por la llamada isDisplayed(). Como sugiere el nombre del método, isDisplayed() es un matcher que coincide con View que se muestran actualmente en la pantalla para el usuario. Por ejemplo, si queremos comprobar si un botón está activado, simplemente pasamos isEnabled() a matches().

Otros dispositivos de comparación popular vista que podemos pasar al método matches() son:

  • hasFocus(): devuelve un matcher que coincide con View que actualmente tienen el foco.
  • isChecked(): devuelve un matcher que acepta solamente si el punto de vista es una CompoundButton (o subtipo) y está en estado facturado. El contrario de este método es isNotChecked().
  • isSelected(): devuelve un matcher que coincide con View seleccionadas.

Para ejecutar la prueba, puede hacer clic en el triángulo verde al lado del método o el nombre de clase. Haga clic en el triángulo verde al lado del nombre de clase se ejecutan todos los métodos de prueba en que clase, mientras el uno al lado de un método ejecutará la prueba sólo para ese método.

MainActivityTest class

¡Hurra! Pasa la prueba!

Android Studio test result toolbar

Realizar Acciones en una View

En un objeto ViewInteraction que es devuelto por la llamada onView(), podemos simular acciones que puede realizar un usuario en un widget. Por ejemplo, podemos simular una acción clic llamando simplemente al método click() estático dentro de la clase ViewActions. Esto devolverá un objeto ViewAction para nosotros.

La documentación dice que ViewAction es:

Responsable de realizar una interacción en el elemento ver.

Realizamos un evento click por primera llamada perform(). Este método realiza las acciones dadas en la vista seleccionada por el matcher de vista actual. Tenga en cuenta que podemos pasar una sola acción o una lista de acciones (ejecutado en orden). Aquí, nos lo dio click(). Otras posibles acciones son:

  • typeText() imitar escribir texto en un EditText.
  • clearText() para simular texto claro en un EditText.
  • doubleClick() para simular hacer doble clic en una View.
  • longClick() imitar larga y haga clic en View.
  • scrollTo() para simular movimiento en sentido vertical un ScrollView que una opinión particular que es View.
  • swipeLeft() para simular pasar de derecha a izquierda en el centro vertical de View.

Muchas más simulaciones se encuentra dentro de la clase ViewActions.

Validar con Afirmaciones de View

Vamos a completar nuestro test para validar que se muestra la pantalla de LoginActivity cuando se hace clic en el botón de Inicio de sesión. Aunque ya hemos visto cómo utilizar check() en un ViewInteraction, vamos a utilizar otra vez, pasar otro ViewAssertion.

Dentro del archivo de diseño de LoginActivity, aparte de EditTextsBotton, también tenemos un TextView con ID R.id.tv_login. Así que simplemente hacer una comprobación para confirmar que el TextView es visible para el usuario.

Ahora puede ejecutar la prueba otra vez!

Android Studio test result toolbar

Las pruebas deben pasar con éxito si has seguido todos los pasos correctamente.

Aquí está lo que sucedió durante el proceso de ejecución de nuestras pruebas:

  1. Lanzó el MainActivity utilizando el campo activityRule.
  2. Verificado si el botón de Inicio de sesión (R.id.btn_login) era visible (isDisplayed()) al usuario.
  3. Simular una acción clic (click()) en ese botón.
  4. Verificar si el LoginActivity se muestra al usuario comprobando si un TextView con id R.id.tv_login en la LoginActivity es visible.

Siempre puede referirse a la hoja de trucos Espresso para ver los dispositivos de comparación de punto de vista diferente, ver acciones y ver afirmaciones disponibles.

6. Prueba de Pantalla de LoginActivity

Este es nuestro LoginActivity.kt:

En el código anterior, si el nombre de usuario introducido es "chike" y la contraseña es "contraseña", entonces el inicio de sesión tiene éxito. Para cualquier otra entrada, es un fracaso. Vamos a escribir ahora una prueba de Espresso para esto!

Ir a LoginActivity.kt, mueva el cursor hasta el nombre LoginActivity y presione Shift-Control-T. Seleccione Crea nueva prueba... en el menú emergente. Seguir el mismo proceso que hicimos para MainActivity.kt y haga clic en el botón Aceptar.

Esta clase de prueba es muy similar a la primera. Si ejecuta la prueba, la pantalla LoginActivity se abre. El nombre de usuario y contraseña se escriben en los campos R.id.et_username y R.id.et_password respectivamente. A continuación, expreso se haga clic en el botón de enviar (R.id.btn_submit). Esperará hasta que View con id R.id.tv_login se puede encontrar con éxito en la lectura del texto.

7. Prueba de un RecyclerView

RecyclerViewActions es la clase que expone un conjunto de APIs para operar en un RecyclerView. RecyclerViewActions es parte de un artefacto separado dentro el artefacto espresso-contrib, que también se debe agregar a build.gradle:

Tenga en cuenta que este artefacto también contiene la API de interfaz de usuario prueba el cajón de la navegación a través de DrawerActions y DrawerMatchers.

Para hacer clic en un elemento en cualquier posición en un RecyclerView, invocamos a actionOnItemAtPosition(). Tenemos que darle un tipo de elemento. En nuestro caso, el punto es la clase ViewHolder dentro nuestro RandomAdapter. Este método toma dos parámetros; la primera es la posición, y la segunda es la acción (ViewActions.click()).

Otros RecyclerViewActions que se pueden realizar son:

  • actionOnHolderItem(): realiza una ViewAction en una vista por viewHolderMatcher. Esto nos permite coincidir por lo que está contenido dentro de la ViewHolder en lugar de la posición.
  • scrollToPosition(): devuelve un ViewAction que RecyclerView se desplaza a una posición.

Siguiente (una vez que el "añadir pantalla note" está abierto), entrará en nuestro texto de la nota y guardar la nota. No tenemos que esperar a la nueva pantalla de abrir, expreso esto hará automáticamente por nosotros. Espera hasta que se encuentra una vista con el id R.id.add_note_title.

8. Prueba de Intenciones

Expreso hace uso de otro artefacto llamado espresso-intents para los intentos de la prueba. Este artefacto es un Espresso que se centra en la validación y burlarse de los intentos. Veamos un ejemplo.

En primer lugar, tenemos que tirar de la biblioteca de espresso-intents en nuestro proyecto.

IntentsTestRule se extiende ActivityTestRule, por lo que ambos tienen comportamientos similares. Esto es lo que dice el doc:

Esta clase es una extensión de ActivityTestRule, que inicializa las calidades de café antes de cada ensayo anotado con Test y lanza calidades de café después de cada prueba. La actividad se dará por terminado después de cada prueba y esta regla puede ser utilizada en la misma forma que ActivityTestRule.

La principal característica diferenciadora es que tiene funcionalidades adicionales para probar startActivity() y startActivityForResult() se burla y talones.

Ahora vamos a probar un escenario donde un usuario hará clic en un botón (R.id.btn_select_contact) en la pantalla para seleccionar un contacto de lista de contactos del teléfono.

Aquí estamos usando intending() de la biblioteca de espresso-intents para establecer un trozo con una respuesta falsa para nuestra petición ACTION_PICK. Esto es lo que sucede en PickContactActivity.kt cuando el usuario hace clic en el botón con id R.id.btn_select_contact para elegir un contacto.

intending() toma en un Matcher que coincide con intentos de que habrá respuesta golpeado. En otras palabras, el Matcher identifica qué solicitud le interesa tropezar. En nuestro caso, hacemos uso de hasAction() (un método auxiliar en IntentMatchers) para encontrar nuestra petición ACTION_PICK. Entonces invocamos a respondWith(), que establece el resultado de onActivityResult(). En nuestro caso, el resultado tiene Activity.RESULT_OK, simulando al usuario seleccionar un contacto de la lista.

Luego simulamos clic en seleccionar contacto, que se llama startActivityForResult(). Tenga en cuenta que nuestro trozo envió la falsa respuesta a onActivityResult().

Por último, utilizamos el método intended() simplemente validar que las llamadas a startActivity() y startActivityForResult() se hicieron con la información correcta.

Conclusión

En este tutorial, aprendió a utilizar fácilmente el marco de prueba expreso en su proyecto de estudio Android para automatizar su flujo de trabajo de prueba.

Recomiendo revisar la documentación oficial para aprender más sobre escritura pruebas de interfaz de usuario con Espresso.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.