Configuración de prueba avanzada

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

En las páginas Cómo realizar pruebas en Android Studio y Cómo realizar pruebas desde la línea de comandos, se explica cómo establecer y ejecutar configuraciones de prueba básicas. Sin embargo, cuando tu aplicación y sus requisitos de prueba se vuelvan más avanzados, es posible que debas adaptar aún más tus configuraciones de prueba. Por ejemplo, es posible que necesites una configuración de prueba avanzada cuando quieras realizar las siguientes acciones:

  • Ejecuta pruebas instrumentadas solo para una variante de compilación específica o anula su configuración de manifiesto.
  • Cambia el tipo de compilación en el que se ejecutan tus pruebas o configura sus opciones de Gradle.
  • Extrae tus pruebas instrumentadas en su propio módulo de prueba.

En esta página, se describen diversas formas de configurar tus pruebas cuando la configuración predeterminada no se ajusta al caso de uso en cuestión.

Cómo crear una prueba instrumentada 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 incluyas pruebas instrumentadas que correspondan a esos conjuntos de orígenes. Esto mantiene organizado el código de prueba y te permite ejecutar solo pruebas que se apliquen a una variante de compilación determinada.

Puedes vincular pruebas instrumentadas a una variante de compilación si las colocas en su propio conjunto de orígenes, que se encuentra en src/androidTestVariantName.

Se comparten las pruebas instrumentadas en el conjunto de orígenes src/androidTest/ 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/.

A fin de agregar un conjunto de orígenes de pruebas para tu variante de compilación en Android Studio, 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 haz clic en OK.

Ahora puedes agregar pruebas a este conjunto de orígenes nuevo siguiendo los pasos 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.

En la siguiente tabla, se muestra un ejemplo de cómo los archivos de prueba de instrumentación pueden residir en conjuntos de orígenes que corresponden a los conjuntos de orígenes de código de la app.

Tabla 1: Código fuente de la app y archivos de prueba de instrumentación correspondientes

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. El motivo es que el conjunto de orígenes de la variante de producto tiene prioridad respecto del conjunto de orígenes principal. Para obtener más información acerca de cómo se combinan los conjuntos de orígenes, consulta Cómo configurar tu compilación.

Cómo configurar ajustes del manifiesto de instrumentación

Las pruebas instrumentadas se compilan en un APK independiente, con su propio archivo AndroidManifest.xml. 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 ese nodo mediante la creación de otro archivo de manifiesto en el conjunto de orígenes de prueba o la configuración del archivo build.gradle a nivel de módulo, como se puede ver en la siguiente muestra de código. Puedes encontrar la lista completa de opciones en la referencia de la API de BaseFlavor.

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

    }
}

Cómo cambiar el tipo de compilación de pruebas

De forma predeterminada, todas las pruebas de instrumentación se ejecutan en el tipo de compilación debug. Puedes cambiarlo por otro tipo de compilación usando la propiedad testBuildType en el archivo build.gradle del nivel de módulo. Por ejemplo, si deseas ejecutar tus pruebas en tu tipo de compilación staging, 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 algunas o todas tus pruebas. En el archivo build.gradle a nivel de módulo, usa el bloque testOptions{} a fin de especificar opciones que cambien la manera en la que Gradle ejecuta todas tus pruebas.

Groovy

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"
    }
}

Kotlin

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 para pruebas de unidades locales únicamente, configura el bloque unitTests{} dentro de testOptions{}.

Groovy

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'
                }
                ...
            }
        }
    }
}

Kotlin

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 = listOf("-XX:MaxPermSize=256m")

                // You can also check the task name to apply options to only the
                // tests you specify.
                if (it.name == "testDebugUnitTest") {
                    systemProperty = mapOf("debug" to "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 build.gradle a nivel del módulo, aplica el complemento com.android.test en lugar de com.android.library.
  3. Para sincronizar tu proyecto, haz clic en Sync Project

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 múltiples variantes de productos, puedes volver a crear esas variantes en tu módulo de prueba y, mediante la administración de dependencias con reconocimiento de variantes, el módulo de prueba intentará probar el tipo coincidente en el módulo de orientación.

De manera predeterminada, los módulos de prueba contienen y prueban solo una variante de depuración. 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 de depuración, usa VariantFilter para inhabilitar la variante de depuración en el proyecto de prueba, como se muestra a continuación:

Groovy

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

Kotlin

android {
    variantFilter {
        if (buildType.name == "debug") {
            ignore = true
        }
    }
}

Si quieres que un módulo de prueba se oriente solamente a algunas clases o algunos tipos de compilación de una app, puedes usar la propiedad matchingFallbacks para apuntar solo a las variantes que deseas probar. Así, también se evita que el módulo de prueba deba configurar esas variantes por sí mismo.