Esta es una breve introducción a la asignación de pruebas y una explicación para comenzar a configurar pruebas 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 versiones
y las reglas de pruebas posteriores al envío directamente en el árbol de fuentes de Android y
las decisiones de las ramas y los dispositivos que se probarán en la infraestructura de prueba.
Las definiciones de asignación de pruebas son archivos JSON llamados TEST_MAPPING
que puedes
en cualquier directorio del código fuente.
Atest puede usar los archivos TEST_MAPPING
para ejecutar pruebas de envío previo en la
directorios asociados. Con la asignación de pruebas, puedes agregar el mismo conjunto de pruebas a
comprobaciones previas con un cambio mínimo en el árbol de fuentes de Android.
Consulta estos ejemplos:
Agrega pruebas previas al envío a
TEST_MAPPING
paraservices.core
Agrega pruebas previas al envío a
TEST_MAPPING
paratools/dexter
usando importaciones
La asignación de pruebas se basa en el agente de prueba Trade Federation (TF) para la ejecución de pruebas y la generación de informes de resultados.
Cómo definir grupos de prueba
Prueba las pruebas de grupos de asignación con un grupo de prueba. El nombre de un grupo de prueba puede ser cualquier cadena. Por ejemplo, presubmit puede ser el nombre de un grupo de pruebas que se ejecutarán cuando se validen los cambios. Y postsubmit pueden ser las pruebas que se usan para validar las compilaciones después de que se combinan los cambios.
Reglas de secuencias de comandos de compilación del paquete
Para que el kit de prueba de Trade Federation ejecute módulos de prueba para una compilación determinada, estos módulos deben tener test_suites
configurado para Soong o LOCAL_COMPATIBILITY_SUITE
configurado para Make en uno de estos dos conjuntos:
general-tests
es para pruebas que no dependen de las capacidades específicas del dispositivo (como el hardware específico del proveedor que la mayoría de los dispositivos no tienen). La mayoría de las pruebas deberían estar en el paquete degeneral-tests
, incluso si son específicas de una ABI o bitness, o funciones de hardware como HWASan (existen un destinotest_suites
independiente para cada ABI) en un dispositivo.device-tests
es para pruebas que dependen de capacidades específicas del dispositivo. Por lo general, estas pruebas se encuentran envendor/
. Específico del dispositivo se refiere solo a las capacidades que son exclusivas de un dispositivo, así que esto se aplica a las pruebas JUnit y las pruebas de GTest (que normalmente deberían marcarse comogeneral-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.
- Se debe realizar una limpieza una vez que haya finalizado, por ejemplo, borrando cualquier archivo de generados durante la prueba.
- Se debe cambiar la configuración del sistema al valor original o predeterminado.
No se debe suponer que un dispositivo se encuentra en un estado determinado, por ejemplo, si 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 raíz, debe especificarlo con
RootTargetPreparer
en suAndroidTest.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, agrega un archivo JSON TEST_MAPPING
.
similar al ejemplo. Estas reglas garantizan que las pruebas se ejecuten
comprobaciones de presubmit cuando se toca algún archivo en ese directorio o en cualquiera de sus
subdirectorios.
Sigue un ejemplo
Este es un archivo TEST_MAPPING
de ejemplo (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": "CtsDeqpTestCases",
"options": [
{
// Use regex in include-filter which is supported in AndroidJUnitTest
"include-filter": "dEQP-EGL.functional.color_clears.*"
}
]
}
],
"imports": [
{
"path": "frameworks/base/services/core/java/com/android/server/am"
}
]
}
Establece atributos
En el ejemplo, 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.
Puedes establecer el nombre del módulo de prueba o el nombre de la prueba de integración de Trade Federation (ruta de acceso al archivo XML de prueba, por ejemplo, uiautomator/uiautomator-demo
) en el valor del atributo name
. Ten en cuenta que el campo name
no
usa la clase name
o el método de prueba name
. Para reducir las pruebas que se ejecutarán,
usa opciones como include-filter
. Consulta
(ejemplo de uso de include-filter
).
La configuración host
de una prueba indica si es una prueba sin dispositivo 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 compatibles son
HostGTest
para
Objetos binarios de GTest y HostTest
para JUnit
y pruebas.
El atributo file_patterns
te permite configurar una lista de cadenas de expresiones regulares
para hacer coincidir la ruta relativa de cualquier archivo de código fuente (relativa al
que contiene el archivo TEST_MAPPING
). En el ejemplo,
la prueba CtsWindowManagerDeviceTestCases
se ejecuta en el envío previo solo cuando se ejecuta un archivo Java
comienza con Window
o Activity
, que se encuentra en el mismo directorio que el
TEST_MAPPING
o cualquiera de sus subdirectorios.
Las barras inversas `` deben tener escape, ya que se encuentran en un archivo JSON.
El atributo imports
te permite incluir pruebas en otros archivos TEST_MAPPING
.
sin copiar el contenido. Los archivos TEST_MAPPING
del elemento superior
directorios de la ruta importada. La asignación de pruebas permite
las importaciones anidadas; Esto significa que dos archivos TEST_MAPPING
pueden importarse entre sí y
la asignación de pruebas puede combinar 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 Manejo de opciones en Tradefed para obtener más información 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:
- Ve al directorio que contiene el archivo
TEST_MAPPING
. Ejecuta el siguiente comando:
atest
Todas las pruebas previas al envío configuradas en los archivos TEST_MAPPING
de la actual
y sus directorios superiores. Atest localiza y ejecuta dos pruebas
para el envío previo (A y B).
Esta es la forma más sencilla de ejecutar pruebas antes del envío en TEST_MAPPING
en el directorio de trabajo actual (CWD) y en los directorios superiores. Atest localiza y usa el archivo TEST_MAPPING
en el CWD y todos sus directorios superiores.
Código fuente de la estructura
En este ejemplo, se muestra cómo configurar 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"
}
]}
Especifica los directorios de destino
Puedes especificar un directorio de destino para ejecutar pruebas en archivos TEST_MAPPING
en ese
. El siguiente comando ejecuta 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 que se definen 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 las pruebas configuradas
del host que no requieren ningún dispositivo. Sin esta opción, Atest ejecuta ambas pruebas,
que requieren un dispositivo y otras que se ejecutan en el host y no requieren ningún dispositivo. El
las pruebas se ejecutan en dos paquetes separados:
atest [--test-mapping] --host
Identifica los grupos de prueba
Puedes especificar grupos de prueba en el comando Atest. El siguiente comando ejecuta
todas las pruebas postsubmit
relacionadas con archivos en el directorio src/project_1
, que
contiene solo una prueba (C).
También puedes usar :all
para ejecutar todas las pruebas, independientemente del grupo. Lo siguiente
ejecuta cuatro pruebas (A, B, C, X):
atest --test-mapping src/project_1:all
Cómo incluir subdirectorios
De forma predeterminada, ejecutar pruebas en TEST_MAPPING
con Atest solo ejecuta pruebas previas al envío configuradas en el archivo TEST_MAPPING
en el CWD (o directorio determinado) y sus directorios superiores. Si quieres ejecutar pruebas en todas
TEST_MAPPING
de los subdirectorios, usa la opción --include-subdir
para
obligar a Atest a incluir también esas pruebas.
atest --include-subdir
Sin la opción --include-subdir
, Atest solo ejecuta la prueba A. Con la
--include-subdir
, Atest ejecuta dos pruebas (A y B).
Se admiten comentarios de nivel de línea
Puedes agregar un comentario de formato //
a nivel de línea para completar la TEST_MAPPING
.
con una descripción de la configuración a continuación.
ATest y la Federación de Comercio
procesa de forma previa TEST_MAPPING
a un formato JSON válido sin comentarios. Para conservar
el archivo JSON limpio, solo el comentario de formato //
a nivel de línea
es compatible.
Ejemplo:
{
// For presubmit test group.
"presubmit": [
{
// Run test on module A.
"name": "A"
}
]
}