Prueba tu app

Android Studio está diseñado para simplificar las pruebas. Con solo algunos clics, puedes configurar una prueba JUnit que se ejecute en el JVM local o una prueba instrumentada que se ejecute en un dispositivo. Por supuesto, también puedes extender tus capacidades de pruebas integrando marcos de trabajo de prueba como Mockito para probar las llamadas de API de Android en tus pruebas de unidades locales, y Espresso o UI Automator para ejercitar la interacción con usuarios en pruebas instrumentadas. Puedes generar pruebas Espresso automáticamente con Espresso Test Recorder.

En esta página, se proporciona información básica sobre cómo agregar pruebas nuevas a tu app y ejecutarlas desde Android Studio.

Para obtener una guía práctica más completa sobre cómo escribir pruebas, consulta Cómo probar apps en Android.

Tipos de pruebas y ubicación

La ubicación del código de tu prueba dependerá del tipo de prueba que escribas. Android Studio proporciona directorios de código fuente (conjuntos fuente) para los siguientes dos tipos de pruebas:

Pruebas de unidad local

Se ubican en module-name/src/test/java/.

Estas son pruebas que se ejecutan en la máquina virtual Java (JVM) local de tu máquina. Usa estas pruebas para minimizar el tiempo de ejecución cuando tus pruebas no tengan dependencias de marco de Android o cuando puedas simular las dependencias del marco de Android.

En el tiempo de ejecución, las pruebas se ejecutan en relación con la versión modificada de android.jar en la que se quitan todos los modificadores final. De esta manera, puedes usar bibliotecas de simulación populares, como Mockito.

Pruebas instrumentadas

Se ubican en module-name/src/androidTest/java/.

Estas son pruebas que se ejecutan en un dispositivo o emulador de hardware. Estas pruebas tienen acceso a las API de Instrumentation, te brindan acceso a información como el Context de la app que estás probando y te permiten controlar la app desde el código de prueba. Usa estas pruebas cuando escribas pruebas de IU integradoras y funcionales para automatizar la interacción de usuarios, o cuando tus pruebas tengan dependencias de Android que los objetos ficticios no puedan contemplar.

Debido a que las pruebas instrumentadas se compilan en un APK (por separado del APK de tu app), deben tener su propio archivo AndroidManifest.xml. Sin embargo, Gradle genera automáticamente este archivo durante la compilación para que no se vea en el conjunto de fuentes de tu proyecto. Puedes agregar tu propio archivo de manifiesto si es necesario, por ejemplo, a fin de especificar un valor diferente para "minSdkVersion" o registrar receptores de ejecución solo para tus pruebas. Cuando se compila tu app, Gradle combina varios archivos de manifiesto en uno solo.

La compilación de Gradle interpreta estos conjuntos de orígenes de pruebas como lo hace en el caso de conjuntos de orígenes de apps de tu proyecto, que te permiten crear pruebas según las variantes de compilación.

Cuando creas un proyecto nuevo o agregas un módulo de app, Android Studio crea los conjuntos de orígenes de pruebas e incluye un ejemplo de archivo de prueba en cada uno. Puedes verlos en la ventana Project, como se muestra en la figura 1.

Figura 1: Las pruebas instrumentadas (1) de tu proyecto y las pruebas JVM locales (2) se pueden ver en la vista Project (izquierda) o Android (derecha)

Cómo agregar una prueba nueva

Para crear una prueba instrumentada o de unidad local, puedes crear una prueba nueva para una clase o un método específico siguiendo estos pasos:

  1. Abre el archivo Java que contenga el código que desees probar.
  2. Haz clic en la clase o el método que desees probar y, luego, presiona Ctrl + mayúscula + T (⇧⌘T).
  3. En el menú que aparece, haz clic en Crear prueba nueva.
  4. En el diálogo Create Test, edita cualquier campo, selecciona cualquier método que quieras generar y haz clic en OK.
  5. En el cuadro de diálogo Choose Destination Directory, haz clic en el conjunto de orígenes que corresponda al tipo de prueba que desees crear: androidTest para una prueba instrumentada o test para una de unidad local. Luego, haz clic en OK.

Como alternativa, puedes crear un archivo Java genérico en el conjunto de orígenes de pruebas correspondiente de la siguiente manera:

  1. En la ventana Project ubicada a la izquierda, haz clic en el menú desplegable y selecciona la vista Project.
  2. Expande la carpeta de módulos correspondientes y la carpeta anidada src. Para agregar una prueba de unidad local, expande la carpeta test y la carpeta anidada java; para agregar una prueba instrumentada, expande la carpeta androidTest y la carpeta anidada java.
  3. En el directorio del paquete de Java, haz clic con el botón derecho y selecciona New > Java Class.
  4. Escribe un nombre para el archivo y, luego, haz clic en OK.

También asegúrate de especificar las dependencias de bibliotecas de pruebas en el archivo build.gradle del módulo de tu app:

dependencies {
        // Required for local unit tests (JUnit 4 framework)
        testImplementation 'junit:junit:4.12'

        // Required for instrumented tests
        androidTestImplementation 'com.android.support:support-annotations:24.0.0'
        androidTestImplementation 'com.android.support.test:runner:0.5'
    }
    

Para obtener dependencias de bibliotecas opcionales y más información sobre cómo escribir tus pruebas, consulta Cómo crear pruebas de unidades locales y Cómo crear pruebas de unidades instrumentadas.

Cómo solucionar conflictos entre el APK de prueba y el de la app

Tanto el APK de la app como su APK de prueba comparten las mismas rutas de clase. Por lo tanto, puedes recibir un error de compilación si los dos APK dependen de distintas versiones de la misma biblioteca. Si Gradle todavía no puede detectar el conflicto de esta versión, es posible que tu app falle o se comporte de manera inesperada durante el tiempo de ejecución.

Para obtener más información, consulta Cómo solucionar errores de resolución de dependencias.

Cómo crear pruebas instrumentadas para una variante de compilación

Si en tu proyecto se incluyen variantes de compilación con conjuntos de orígenes únicos, te recomendamos que uses conjuntos de orígenes de una prueba instrumentada correspondiente. La creación de pruebas instrumentadas en conjuntos de orígenes que corresponden a tus variantes de compilación permite mantener organizado tu código de prueba y ejecutar solo las pruebas que se apliquen a una variante de compilación determinada.

Si deseas agregar un conjunto de orígenes de pruebas para tu variante de compilación, sigue estos pasos:

  1. En la ventana Project ubicada a la izquierda, haz clic en el menú desplegable y selecciona la vista Project.
  2. Dentro de la carpeta de módulo correspondiente, haz clic con el botón derecho en la carpeta src y selecciona New > Directory.
  3. Como nombre del directorio, escribe "androidTestVariantName". Por ejemplo, si tienes una variante de compilación llamada "MyFlavor", el nombre del directorio debe ser "androidTestMyFlavor". Luego, haz clic en OK.
  4. Haz clic con el botón derecho en el directorio nuevo y selecciona New > Directory.
  5. Escribe "java" como nombre de directorio y, luego, haz clic en OK.

Ahora puedes agregar pruebas a este conjunto de orígenes nuevo si sigues los pasos anteriores para agregar una prueba nueva. Cuando llegues al diálogo Choose Destination Directory, selecciona el conjunto de orígenes de prueba de la variante nueva.

Las pruebas instrumentadas en el conjunto de orígenes src/androidTest/ se comparten en todas las variantes de compilación. Cuando se compila un APK de prueba para la variante "MyFlavor" de tu app, Gradle combina los conjuntos de orígenes src/androidTest/ y src/androidTestMyFlavor/.

Por ejemplo, en la siguiente tabla, se muestra la manera en que los archivos de prueba de instrumentación residen en conjuntos de orígenes que se corresponden con conjuntos de orígenes de código de la app.

Ruta de acceso a la clase de app Ruta de acceso para hacer coincidir la clase de prueba de instrumentación
src/main/java/Foo.java src/androidTest/java/AndroidFooTest.java
src/myFlavor/java/Foo.java src/androidTestMyFlavor/java/AndroidFooTest.java

Del mismo modo en que lo hace para tus conjuntos de orígenes de apps, la compilación de Gradle combina y anula los archivos de diferentes conjuntos de orígenes de prueba. En este caso, el archivo AndroidFooTest.java del conjunto de orígenes "androidTestMyFlavor" anula la versión en el conjunto de orígenes "androidTest". Para obtener más información acerca de cómo se combinan conjuntos de orígenes, consulta Cómo configurar tu compilación.

Otra razón por la cual debes usar variantes de compilación para tu app y conjuntos de orígenes de pruebas es la creación de pruebas cerradas a través de dependencias ficticias. Es decir, puedes crear una clase de producto para tu app que contenga implementaciones falsas de dependencias (como solicitudes de red o datos de sensores de dispositivos que sean poco confiables) y, luego, puedes agregar un conjunto de orígenes de prueba ficticios correspondiente. Para obtener más información, consulta la publicación de blog sobre cómo aprovechar tipos de productos para pruebas herméticas.

Cómo configurar ajustes del manifiesto de instrumentación

Cuando Gradle compila tu APK de prueba, genera automáticamente el archivo AndroidManifest.xml y lo configura con el nodo <instrumentation>. Uno de los motivos por los que Gradle configura este nodo es para que puedas asegurarte de que la propiedad targetPackage especifique el nombre de paquete correcto de la app que estás probando. Puedes cambiar algunas configuraciones de este nodo si creas otro archivo de manifiesto en el conjunto de fuentes de prueba o configuras tu archivo build.gradle a nivel de módulo, como se muestra en el siguiente ejemplo de código.

    android {
      ...
      // Each product flavor you configure can override properties in the
      // defaultConfig {} block. To learn more, go to Configure product flavors.
      defaultConfig {
        ...
        // Specifies the application ID for the test APK.
        testApplicationId "com.test.foo"
        // Specifies the fully-qualified class name of the test instrumentation runner.
        testInstrumentationRunner "android.test.InstrumentationTestRunner"
        // If set to 'true', enables the instrumentation class to start and stop profiling.
        // If set to false (default), profiling occurs the entire time the instrumentation
        // class is running.
        testHandleProfiling true
        // If set to 'true', indicates that the Android system should run the instrumentation
        // class as a functional test. The default value is 'false'
        testFunctionalTest true
      }
    }
    ...
    

Cambiar el tipo de compilación de pruebas

De forma predeterminada, todas las pruebas se ejecutan en el tipo de compilación de depuración. Para usar otro tipo de compilación, utiliza la propiedad testBuildType en el archivo build.gradle a nivel de módulo. Por ejemplo si deseas ejecutar pruebas en tu tipo de compilación "staging" (etapa de pruebas), edita el archivo como se muestra en el siguiente fragmento.

android {
        ...
        testBuildType "staging"
    }
    

Cómo configurar opciones de prueba de Gradle

El complemento de Android para Gradle te permite especificar determinadas opciones para todas tus unidades de prueba o algunas de ellas. En el archivo build.gradle a nivel de módulo, usa el bloque testOptions {} para especificar opciones que cambien la manera en la que Gradle ejecuta todas tus pruebas.

    android {
      ...
      // Encapsulates options for running tests.
      testOptions {
        // Changes the directory where Gradle saves test reports. By default, Gradle saves test reports
        // in the path_to_your_project/module_name/build/outputs/reports/ directory.
        // '$rootDir' sets the path relative to the root directory of the current project.
        reportDir "$rootDir/test-reports"
        // Changes the directory where Gradle saves test results. By default, Gradle saves test results
        // in the path_to_your_project/module_name/build/outputs/test-results/ directory.
        // '$rootDir' sets the path relative to the root directory of the current project.
        resultsDir "$rootDir/test-results"
      }
    }
    

Si deseas especificar opciones solo para las pruebas de unidades locales, configura el bloque unitTests {} dentro de testOptions {}.

    android {
      ...
      testOptions {
        ...
        // Encapsulates options for local unit tests.
        unitTests {
          // By default, local unit tests throw an exception any time the code you are testing tries to access
          // Android platform APIs (unless you mock Android dependencies yourself or with a testing
          // framework like Mockito). However, you can enable the following property so that the test
          // returns either null or zero when accessing platform APIs, rather than throwing an exception.
          returnDefaultValues true

          // Encapsulates options for controlling how Gradle executes local unit tests. For a list
          // of all the options you can specify, read Gradle's reference documentation.
          all {
            // Sets JVM argument(s) for the test JVM(s).
            jvmArgs '-XX:MaxPermSize=256m'

            // You can also check the task name to apply options to only the tests you specify.
            if (it.name == 'testDebugUnitTest') {
              systemProperty 'debug', 'true'
            }
            ...
          }
        }
      }
    }
    

Cómo usar módulos de prueba individuales para pruebas instrumentadas

Si deseas tener un módulo dedicado para pruebas instrumentadas y aislar el resto del código de las pruebas, puedes crear un módulo de prueba por separado y configurar su compilación del mismo modo que con un módulo de bibliotecas. Para crear un módulo de prueba, sigue estos pasos:

  1. Crea un módulo de biblioteca.
  2. En el archivo de compilación a nivel de módulo, aplica el complemento com.android.test en lugar de com.android.library.
  3. Sincroniza tu proyecto.

Después de crear el módulo de prueba, puedes incluir el código de prueba en el conjunto de orígenes principal o de la variante (por ejemplo, src/main/java o src/variant/java). Si el módulo de tu app define varios tipos de productos, puedes volver a crear esos tipos en tu módulo de prueba y, mediante la administración de dependencias con reconocimiento de variantes, el módulo de prueba intenta probar el tipo coincidente en el módulo de orientación.

De manera predeterminada, los módulos de prueba incluyen y prueban solo una variante de debug. Sin embargo, puedes crear tipos de compilación nuevos que coincidan con el proyecto de app sometido a prueba. Si deseas que el módulo pruebe un tipo de compilación diferente, y no la compilación de depuración, usa VariantFilter para inhabilitar la variante de debug en el proyecto de prueba, como se muestra a continuación:

android {
        variantFilter { variant ->
            if (variant.buildType.name.equals('debug')) {
                variant.setIgnore(true);
            }
        }
    }
    

Si quieres que un módulo de prueba se oriente solo a determinadas variantes o tipos de compilación de una app, puedes usar la propiedad matchingFallbacks a fin de orientarte solo las variantes que deseas probar. De esta manera, también evitas que el módulo de prueba tenga que configurar esas variantes para sí mismo.

Cómo ejecutar una prueba

Para ejecutar una prueba, haz lo siguiente:

  1. Asegúrate de que tu proyecto esté sincronizado con Gradle. Para ello, haz clic en la opción Sync Project de la barra de herramientas.
  2. Ejecuta tu prueba de una de las siguientes maneras:
    • En la ventana Project, haz clic con el botón derecho y selecciona Run .
    • En el editor de código, haz clic con el botón derecho en una clase o un método del archivo de prueba, y selecciona Run a fin de ejecutar todos los métodos en la clase.
    • Para ejecutar todas las pruebas, haz clic con el botón derecho en el directorio de prueba y selecciona Run tests .

De forma predeterminada, tu prueba se ejecuta con la configuración de ejecución predeterminada de Android Studio. Si deseas cambiar alguna de las configuraciones de ejecución, como las opciones del ejecutor de instrumentación y de implementación, puedes editar la configuración de ejecución en el diálogo Run/Debug Configurations (haz clic en Run > Edit Configurations).

Cómo ver la cobertura de pruebas

La herramienta de cobertura de pruebas está disponible para las pruebas de unidades locales a fin de realizar un seguimiento del porcentaje y las áreas del código de tu app que abarcaron las pruebas de tu unidad. Usa la herramienta de cobertura de pruebas para determinar si probaste correctamente los elementos, las clases, los métodos y las líneas de código que forman parte de tu app.

Hay varias maneras de ejecutar la prueba de una unidad, como se describe en la página Running with Coverage de IntelliJ. En el siguiente procedimiento, se muestra cómo intercalar las pruebas de unidades desde el editor:

  1. Haz doble clic en la prueba de unidades que quieras ejecutar.
  2. En el editor, coloca el cursor sobre la línea que quieras ejecutar con la cobertura.
    • Si colocas el cursor en la declaración de clases, se ejecutarán todos los métodos de prueba en esa clase.
    • Si colocas el cursor en una declaración de métodos, se ejecutará todo el código en ese método.
    • Si colocas el cursor en una línea específica de un método, solo se ejecutará esa línea.
  3. Haz clic con el botón derecho en la línea en la que colocaste el cursor.
  4. En el menú contextual, selecciona Run test-name with coverage.

    Aparecerá la ventana de herramientas de cobertura.

En la figura 2, se muestra la ventana de herramientas de cobertura de una prueba de unidades de cálculo (suma, resta, multiplicación y división).

Figura 2: Consulta los porcentajes de cobertura de código de tu app

Para obtener más información sobre las pruebas de unidades locales, consulta Cómo crear pruebas de unidades locales.

Cómo ver los resultados de la prueba

Cuando ejecutas una prueba instrumentada o de JUnit, los resultados de muestran en la ventana Run. Una barra verde significa que se realizaron correctamente todas las pruebas, mientras que una roja indica que falló al menos una. La figura 3 muestra una prueba de ejecución que se ejecutó de manera correcta.

Figura 3: Los resultados de la prueba se muestran en la ventana "Run"

En la ventana Run, se muestran las pruebas en una vista de árbol a la izquierda, mientras que los resultados y mensajes del conjunto de pruebas actual aparecen en el panel de resultados de la derecha. Usa las barras de herramientas, los menús contextuales y los íconos de estado para administrar los resultados de pruebas de la siguiente manera:

  1. Usa la barra de herramientas de ejecución para volver a ejecutar o detener la prueba actual, volver a ejecutar las pruebas con errores (que no se muestran porque solo está disponible para las pruebas de unidades), pausar los resultados y volcar conversaciones.
  2. Usa la barra de herramientas de pruebas para filtrar y ordenar resultados de pruebas. También puedes expandir o contraer nodos, mostrar la cobertura de la prueba y exportar o importar resultados de pruebas.
  3. Haz clic en el menú contextual para realizar un seguimiento de la prueba de ejecución, mostrar las estadísticas de intercalado, abrir el código fuente en una excepción, desplazarte automáticamente a la fuente y seleccionar la primera prueba con errores una vez que se completa la ejecución.
  4. Los íconos de estado de la prueba indican si una prueba tiene un error, se la ignoró, falló, está en curso, se completó correctamente, está pausada, se la canceló o no se la ejecutó.
  5. Haz clic con el botón derecho en una línea en la vista de árbol para ver un menú contextual que te permita ejecutar las pruebas en el modo de depuración, abrir el archivo de código fuente de la prueba o saltar a la línea del código fuente que se está probando.

Para obtener más información sobre la ventana Run, sus barras de herramientas y los menús contextuales, consulta la página de IntelliJ sobre la pestaña del ejecutor de pruebas.

Cómo ver las estadísticas de intercalado

Si deseas saber cuánto tiempo tardaron en ejecutarse las pruebas, haz lo siguiente:

  1. Haz clic en el ícono de engranaje .
  2. En la lista desplegable, selecciona Show Inline Statistics.

    El tiempo transcurrido en milésimas de segundo se muestra a la derecha de las pruebas.

Cómo comparar strings

Si la prueba de una unidad incluye errores de assertEquals() a partir de la comparación de dos objetos de strings, puedes ver cuáles son las diferencias entre los dos objetos de strings a fin de averiguar el motivo de los errores. Para ello, sigue estos pasos:

  1. En el panel de resultados, haz clic en el vínculo Click to see difference.
  2. En Differences viewer, explora las diferencias como se describe en la página Differences viewer for files de IntelliJ.

Cómo exportar resultados de pruebas

Puedes exportar los resultados de tu prueba en formato XML o HTML de la siguiente manera:

  1. Haz clic en Export Test Results .
  2. En el diálogo Export Test Results, indica la información de formato y resultados, y haz clic en OK.

    Los resultados de la prueba exportados se guardan en la carpeta especificada.

Cómo importar resultados de prueba

Puedes importar tus resultados de la prueba exportados de la siguiente manera:

  1. Haz clic en Import Test Results .
  2. En el menú desplegable, selecciona el archivo que desees importar.

    Los resultados de la prueba importados se mostrarán en la ventana Run.