Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Mapeo de prueba

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

¿Qué es el mapeo de prueba?

Test Mapping es un enfoque basado en Gerrit que permite a los desarrolladores crear reglas de prueba previas y posteriores al envío directamente en el árbol de origen de Android y dejar que las decisiones de las ramas y los dispositivos se prueben en la propia infraestructura de prueba. Las definiciones de mapeo de prueba son archivos JSON denominados TEST_MAPPING que se pueden colocar en cualquier directorio de origen.

Atest puede utilizar los archivos TEST_MAPPING para ejecutar las pruebas de presentar previamente en los directorios asociados. Con Test Mapping, puede agregar el mismo conjunto de pruebas para preenviar verificaciones con un simple cambio dentro del árbol de fuentes de Android.

Vea estos ejemplos:

Agregue pruebas de envío previo a TEST_MAPPING para services.core

Agregue pruebas de preenvío a TEST_MAPPING para herramientas / dexter usando importaciones

Mapeo de prueba se basa en la Federación de Comercio (TF) arnés de prueba para la ejecución de las pruebas y los resultados de informes.

Definición de grupos de prueba

Asignación de grupos de prueba Las pruebas a través de un grupo de prueba. El nombre de un grupo de prueba puede ser cualquier cadena. Por ejemplo, presentar previamente puede ser para un grupo de pruebas para ejecutar al validar cambios. Y las pruebas postsubmit se pueden utilizar para validar las compilaciones después de los cambios se fusionan.

Empaquetar reglas de secuencia de comandos de compilación

Para que el instrumento de prueba Federación de Comercio para ejecutar módulos de prueba de Asignación de prueba para una construcción dada, estos módulos deben tener test_suite conjunto de Soong o LOCAL_COMPATIBILITY_SUITE conjunto de make a una de estas dos suites:

  • -tests generales - exámenes que no dependen de las características específicas del dispositivo. La mayoría de las pruebas deben estar en el conjunto de pruebas generales, ya que se pueden construir en el destino test_suites que incluye los binarios (para las pruebas nativas) en todas las ABI compatibles (32 frente a 64).
  • dispositivo de pruebas - pruebas dependen de las características específicas del dispositivo, ejecutable sólo en ciertos destinos de dispositivo, o sólo pueden construirse sólo en ciertos destinos de dispositivo. Esto es cierto si la prueba es una prueba nativa o una prueba JUnit.

Ejemplos:

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

Configuración de pruebas para que se ejecuten en una suite de pruebas

Para que una prueba se ejecute dentro de un conjunto de pruebas, la prueba:

  • no debe tener ningún proveedor de compilación.
  • debe limpiarse una vez finalizada, por ejemplo, eliminando los archivos temporales generados durante la prueba.
  • cambie la configuración del sistema al valor predeterminado u original.

  • no debe asumir un dispositivo en un cierto estado, por ejemplo, root listo. La mayoría de las pruebas no requieren privilegios de root para ejecutarse. Si una prueba debe requerir root, debe especificarlo con un RootTargetPreparer, por ejemplo:

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

Crear archivos de mapeo de prueba

Para el directorio que requiere cobertura de prueba, simplemente agregue un archivo JSON TEST_MAPPING que se parezca al ejemplo siguiente. Estas reglas asegurarán que las pruebas se ejecuten en comprobaciones previas al envío cuando se toque algún archivo en ese directorio o en cualquiera de sus subdirectorios.

Siguiendo un ejemplo

Este es un ejemplo TEST_MAPPING archivo (está en formato JSON, pero con el apoyo 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 native test with options.
    {
      "name" : "hello_world_test",
      "options": [
        {
          "native-test-flag": "\"servicename1 servicename2\""
        },
        {
          "native-test-timeout": "6000"
        }
      ]
    }
    // Host-side native test.
    {
      "name" : "net_test_avrcp",
      "host" : true
    }
  ],
  "postsubmit": [
    {
      "name": "CtsWindowManagerDeviceTestCases"
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

Establecer atributos

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

El nombre del módulo de prueba o de la Federación de Comercio nombre de la prueba de integración (ruta del recurso en el archivo XML de prueba, por ejemplo, uiautomator / uiautomator-demo ) se puede ajustar en el valor del name atributo. Tenga en cuenta el campo de nombre no puede utilizar la clase name o método de ensayo name . Para reducir el número de pruebas a ejecutar, puede utilizar opciones como include-filter aquí. Ver ( incluir-filtro de ejemplos de uso ).

La configuración de anfitrión de una prueba indica si la prueba es una prueba sin dispositivos que se ejecutan en serie o no. El valor predeterminado es falso, es decir, la prueba requiere un dispositivo para funcionar. Los tipos de prueba admitidos son HostGTest para las pruebas nativas y HostTest para las pruebas JUnit.

El atributo file_patterns le permite configurar una lista de cadenas de expresiones regulares para hacer coincidir la ruta relativa de cualquier archivo de código fuente (en relación con el directorio que contiene el archivo TEST_MAPPING). En el ejemplo anterior, las pruebas CtsWindowManagerDeviceTestCases se ejecutarán en presentar previamente sólo cuando ningún archivo Java se inicia con la ventana o de la actividad, que existe en el mismo directorio del archivo TEST_MAPPING o cualquiera de sus subdirectorios, se cambia. Las barras invertidas \ deben escaparse, ya que están en un archivo JSON.

El atributo importaciones le permite incluir pruebas en otros archivos TEST_MAPPING sin copiar el contenido. Tenga en cuenta que también se incluirán los archivos TEST_MAPPING en los directorios principales de la ruta importada. Test Mapping permite importaciones anidadas; esto significa que dos archivos TEST_MAPPING pueden importarse entre sí, y Test Mapping puede fusionar correctamente las pruebas incluidas.

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

Para obtener una lista completa de las opciones disponibles para una prueba determinada, ejecute:

tradefed.sh run commandAndExit [test_module] --help

Consulte la opción TradeFed manipulación para más detalles acerca de cómo las opciones de trabajo.

Ejecución de pruebas con Atest

Para ejecutar las reglas de prueba de preenvío localmente:

  1. Vaya al directorio que contiene el archivo TEST_MAPPING.
  2. Ejecute el comando:
atest

Se ejecutan todas las pruebas de preenvío configuradas en los archivos TEST_MAPPING del directorio actual y sus directorios principales. Atest localizará y ejecutará dos pruebas para preenvío (A y B).

Esta es la forma más sencilla de ejecutar pruebas de preenvío en archivos TEST_MAPPING en el directorio de trabajo actual (CWD) y los directorios principales. Atest localizará y utilizará el archivo TEST_MAPPING en CWD y todos sus directorios principales.

Estructuración del código fuente

El siguiente ejemplo muestra cómo se pueden configurar los archivos TEST_MAPPING en el árbol de origen.

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

Especificar directorios de destino

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

atest --test-mapping src/project_1

Ejecución de reglas de prueba posteriores al envío

También puede utilizar este comando para ejecutar las reglas de prueba postsubmit definidos en TEST_MAPPING en src_path (por defecto a la caquexia crónica) y sus directorios padre:

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

Ejecutar solo pruebas que no requieren dispositivo

Puede usar la opción de --host Atest a pruebas única carrera configurados contra el anfitrión que no requieren ningún dispositivo. Sin esta opción, Atest ejecutará ambas pruebas, las que requieren dispositivo y las que se ejecutan en el host y no requieren dispositivo. Las pruebas se ejecutarán en dos conjuntos separados.

atest [--test-mapping] --host

Identificación de grupos de prueba

Puede especificar grupos de prueba en el comando Atest. El siguiente comando ejecutar todas las pruebas postsubmit relacionados con los archivos en el directorio src / Proyecto_1, que contiene una sola prueba (C).

O puede utilizar: todos a ejecutar todas las pruebas, independientemente de grupo. El siguiente comando ejecuta cuatro pruebas (A, B, C, X):

atest --test-mapping src/project_1:all

Incluyendo subdirectorios

De forma predeterminada, la ejecución de pruebas en TEST_MAPPING con Atest ejecutará solo las pruebas de preenvío configuradas en el archivo TEST_MAPPING en CWD (o directorio dado) y sus directorios principales. Si desea ejecutar pruebas en todos los archivos TEST_MAPPING en los subdirectorios, utilice la opción --include-subdir para forzar Atest para incluir esas pruebas también.

atest --include-subdir

Sin la --include-subdir opción, Atest sólo se ejecutará la prueba A. Con el --include-subdir opción, Atest se ejecutará dos pruebas (A, B).

Se admiten comentarios a nivel de línea

Se puede añadir un nivel de línea // comentario -format de profundizar en el archivo TEST_MAPPING con la descripción del entorno que le sigue. ATest y la Federación de Comercio se puede procesar previamente el TEST_MAPPING a un formato JSON válida sin comentarios. Para mantener el archivo JSON limpio y fácil de leer, sólo el nivel de línea // comentario -format es compatible.

Ejemplo:

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