Probar la asignación

Esta es una breve introducción a la asignación de pruebas y una explicación sobre cómo comenzar a configurar pruebas fácilmente en el Proyecto de código abierto de Android (AOSP).

Información acerca de la asignación de pruebas

La asignación de pruebas es un enfoque basado en Gerrit que permite a los desarrolladores crear reglas de pruebas previas y posteriores al envío directamente en el árbol de fuentes de Android, y dejar las decisiones de las ramas y dispositivos que se probarán en la infraestructura de prueba. Las definiciones de asignación de pruebas son archivos JSON llamados TEST_MAPPING que se pueden ubicar en cualquier directorio del código fuente.

Atest puede usar los archivos TEST_MAPPING para ejecutar pruebas de envío previo en los directorios asociados. Con la asignación de pruebas, puedes agregar el mismo conjunto de pruebas para enviar previamente las verificaciones con un cambio simple dentro del árbol de fuentes de Android.

Consulta estos ejemplos:

Agrega pruebas previas al envío a TEST_MAPPING para services.core

Cómo agregar pruebas de envío previo a TEST_MAPPING para herramientas/dexter mediante importaciones

La asignación de pruebas se basa en el agente de pruebas de la Federación de Comercio (TF) para la ejecución de pruebas y los informes de resultados.

Cómo definir grupos de prueba

Probar la asignación de grupos de pruebas a través de un grupo de prueba El nombre de un grupo de prueba puede ser cualquier cadena. Por ejemplo, presubmit puede ser para que un grupo de pruebas se ejecuten cuando se validan los cambios. Las pruebas postsubmit se pueden usar para validar las compilaciones después de combinar los cambios.

Reglas de secuencias de comandos de compilación del paquete

Para que el agente de prueba de la Federación de Comercio ejecute los módulos de prueba de la asignación de pruebas para una compilación determinada, estos deben tener los test_suites configurados para Soong o LOCAL_COMPATIBILITY_SUITE establecidos para Make en uno de estos dos paquetes:

• general-tests: Pruebas que no dependen de la funcionalidad específica del dispositivo (como el hardware específico del proveedor que la mayoría de los dispositivos no tiene). La mayoría de las pruebas deben pertenecer al paquete de pruebas generales, incluso si son específicas de una ABI o bits, o funciones de hardware como HWASan (hay un objetivo test_suites diferente para cada ABI) e incluso si tienen que ejecutarse en un dispositivo.
• device-tests: Pruebas que dependen de la funcionalidad específica del dispositivo. Por lo general, estas pruebas se encuentran por debajo de vendor/. Debido a que "específico del dispositivo" no hace referencia a la funcionalidad de ABI o SoC que otros dispositivos podrían o no tener, sino solo a la funcionalidad que es exclusiva de un dispositivo, esto se aplica tanto a las pruebas JUnit como a las pruebas nativas de GTest (que suelen ser general-tests, incluso si son específicas de ABI).

Ejemplos:

Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests

Cómo configurar pruebas para ejecutarlas en un paquete de pruebas

Para que una prueba se ejecute dentro de un paquete de pruebas, la prueba debe cumplir con lo siguiente:

• no debe tener ningún proveedor de compilación.
• debe limpiarse una vez finalizada, por ejemplo, borrando los archivos temporales generados durante la prueba.
• cambiar la configuración del sistema al valor original o predeterminado
• no deben suponer que un dispositivo se encuentra en un estado determinado, p.ej., cuando está listo para usar la función de administrador. La mayoría de las pruebas no requieren privilegios de raíz para ejecutarse. Si una prueba debe requerir permisos de administrador, debe especificarlo con RootTargetPreparer en su AndroidTest.xml, como en el siguiente ejemplo:

<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>

Crea archivos de asignación de prueba

Para el directorio que requiere cobertura de pruebas, simplemente agrega un archivo JSON TEST_MAPPING similar al siguiente ejemplo. Estas reglas garantizarán que las pruebas se ejecuten en comprobaciones del envío previo cuando se toque algún archivo en ese directorio o en cualquiera de sus subdirectorios.

Sigue un ejemplo

Este es un archivo TEST_MAPPING de muestra (está en formato JSON, pero admite comentarios):

{
  "presubmit": [
    // JUnit test with options and file patterns.
    {
      "name": "CtsWindowManagerDeviceTestCases",
      "options": [
        {
          "include-annotation": "android.platform.test.annotations.RequiresDevice"
        }
      ],
      "file_patterns": ["(/|^)Window[^/]*\\.java", "(/|^)Activity[^/]*\\.java"]
    },
    // Device-side GTest with options.
    {
      "name" : "hello_world_test",
      "options": [
        {
          "native-test-flag": "\"servicename1 servicename2\""
        },
        {
          "native-test-timeout": "6000"
        }
      ]
    }
    // Host-side GTest.
    {
      "name" : "net_test_avrcp",
      "host" : true
    }
  ],
  "postsubmit": [
    {
      "name": "CtsWindowManagerDeviceTestCases"
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

Establece atributos

En el ejemplo anterior, presubmit y postsubmit son los nombres de cada grupo de prueba. Consulta Define grupos de prueba para obtener más información sobre los grupos de prueba.

El nombre del módulo de prueba o el nombre de la prueba de integración de la Federación de Comercio (ruta de acceso a los recursos al archivo en formato XML de prueba, p.ej., uiautomator/uiautomator-demo) se puede establecer en el valor del atributo name. Ten en cuenta que el campo name no puede usar la clase name ni el método de prueba name. Para reducir las pruebas que se ejecutarán, puedes usar opciones como include-filter aquí. Consulta (uso de muestra de filtro de inclusión).

La configuración de host de una prueba indica si esta es una prueba sin dispositivos que se ejecuta en el host o no. El valor predeterminado es false, lo que significa que la prueba requiere un dispositivo para ejecutarse. Los tipos de prueba admitidos son HostGTest para los objetos binarios de GTest y HostTest para las pruebas JUnit.

El atributo file_patterns te permite configurar una lista de strings de regex para coincidir con la ruta de acceso relativa de cualquier archivo de código fuente (relativo al directorio que contiene el archivo TEST_MAPPING). En el ejemplo anterior, la prueba CtsWindowManagerDeviceTestCases se ejecutará en el envío previo solo cuando se modifique cualquier archivo Java con Window o Activity, que exista en el mismo directorio del archivo TEST_MAPPING o cualquiera de sus subdirectorios. Se deben escapar las barras inversas, ya que se encuentran en un archivo JSON.

El atributo imports te permite incluir pruebas en otros archivos TEST_MAPPING sin copiar el contenido. Ten en cuenta que también se incluirán los archivos TEST_MAPPING de los directorios superiores de la ruta importada. La asignación de pruebas permite las importaciones anidadas; es decir, dos archivos TEST_MAPPING pueden importarse entre sí y la asignación de pruebas puede combinar correctamente las pruebas incluidas.

El atributo options contiene opciones adicionales de la línea de comandos de TradeFed.

Para obtener una lista completa de las opciones disponibles para una prueba determinada, ejecuta lo siguiente:

tradefed.sh run commandAndExit [test_module] --help

Consulta Control de opciones de TradeFed para obtener más detalles sobre cómo funcionan las opciones.

Ejecutar pruebas con Atest

Para ejecutar las reglas de prueba previa al envío de forma local, haz lo siguiente:

1. Ve al directorio que contiene el archivo TEST_MAPPING.
2. Ejecuta el siguiente comando:

atest

Se ejecutan todas las pruebas de envío previo configuradas en los archivos TEST_MAPPING del directorio actual y sus directorios superiores. Atest ubicará y ejecutará dos pruebas para el envío previo (A y B).

Esta es la forma más sencilla de ejecutar pruebas de envío previo en los archivos TEST_MAPPING del directorio de trabajo (CWD) y los directorios superiores actuales. Atest ubicará y usará el archivo TEST_MAPPING en CWD y en todos sus directorios superiores.

Código fuente de la estructura

En el siguiente ejemplo, se muestra cómo se pueden configurar los archivos TEST_MAPPING en el árbol de fuentes.

src
├── project_1
│   └── TEST_MAPPING
├── project_2
│   └── TEST_MAPPING
└── TEST_MAPPING

Contenido de src/TEST_MAPPING:

{
  "presubmit": [
    {
      "name": "A"
    }
  ]
}

Contenido de src/project_1/TEST_MAPPING:

{
  "presubmit": [
    {
      "name": "B"
    }
  ],
  "postsubmit": [
    {
      "name": "C"
    }
  ],
  "other_group": [
    {
      "name": "X"
    }
  ]}

Contenido de src/project_2/TEST_MAPPING:

{
  "presubmit": [
    {
      "name": "D"
    }
  ],
  "import": [
    {
      "path": "src/project_1"
    }
  ]}

Cómo especificar directorios de destino

Puedes especificar un directorio de destino para ejecutar pruebas en los archivos TEST_MAPPING de ese directorio. El siguiente comando ejecutará dos pruebas (A y B).

atest --test-mapping src/project_1

Ejecuta reglas de prueba posteriores al envío

También puedes usar este comando para ejecutar las reglas de prueba posteriores al envío definidas en TEST_MAPPING en src_path (la configuración predeterminada es CWD) y sus directorios superiores:

atest [--test-mapping] [src_path]:postsubmit

Ejecutar solo pruebas que no requieran ningún dispositivo

Puedes usar la opción --host para que Atest solo ejecute pruebas configuradas en el host que no requieran ningún dispositivo. Sin esta opción, Atest ejecutará ambas pruebas, las que requieren el dispositivo y las que se ejecutan en el host, y no requieren dispositivo. Las pruebas se ejecutarán en dos paquetes separados.

atest [--test-mapping] --host

Identifica grupos de prueba

Puedes especificar grupos de prueba en el comando Atest. El siguiente comando ejecutará todas las pruebas de postsubmit relacionadas con los archivos del directorio src/project_1, que contiene solo una prueba (C).

O puedes usar :all para ejecutar todas las pruebas sin importar el grupo. El siguiente comando ejecuta cuatro pruebas (A, B, C, X):

atest --test-mapping src/project_1:all

Incluir subdirectorios

De forma predeterminada, la ejecución de pruebas en TEST_MAPPING con Atest solo ejecutará las pruebas de envío previo configuradas en el archivo TEST_MAPPING en CWD (o directorio proporcionado) y sus directorios superiores. Si deseas ejecutar pruebas en todos los archivos TEST_MAPPING de los subdirectorios, usa la opción --include-subdir para forzar a Atest a que también incluya esas pruebas.

atest --include-subdir

Sin la opción --include-subdir, Atest solo ejecutará la prueba A. Con la opción --include-subdir, Atest ejecutará dos pruebas (A y B).

Se admite el comentario a nivel de línea

Puedes agregar un comentario en formato // a nivel de línea para completar el archivo TEST_MAPPING con una descripción de la configuración que aparece a continuación. ATest y Trade Federation procesarán previamente TEST_MAPPING a un formato JSON válido sin comentarios. Para mantener el archivo JSON limpio y fácil de leer, solo se admite el comentario en formato // a nivel de línea.

Ejemplo:

{
  // For presubmit test group.
  "presubmit": [
    {
      // Run test on module A.
      "name": "A"
    }
  ]
}