Google se compromete a promover la equidad racial para las comunidades negras. Ver cómo.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Agregar un nuevo ejemplo de prueba nativa

Si es nuevo en el desarrollo de la plataforma Android, puede encontrar este ejemplo completo de agregar una nueva prueba nativa desde cero útil para demostrar el flujo de trabajo típico involucrado. Además, si no está familiarizado con el marco gtest para C ++, revise el sitio del proyecto gtest para obtener documentación adicional.

Esta guía utiliza la siguiente prueba para servir como muestra:

Hello World Native Test

Se recomienda examinar primero el código para obtener una impresión aproximada antes de continuar.

Decidir sobre una ubicación de origen

Por lo general, su equipo ya tendrá un patrón establecido de lugares para registrar el código y lugares para agregar pruebas. La mayoría del equipo posee un único repositorio git, o comparte uno con otros equipos, pero tiene un subdirectorio dedicado que contiene el código fuente del componente.

Suponiendo que la ubicación de la raíz de su fuente de componentes está en <component source root> , la mayoría de los componentes tienen src y carpetas de tests debajo, y algunos archivos adicionales como Android.mk (o divididos en archivos .bp adicionales).

Dado que está agregando una nueva prueba, es probable que deba crear el directorio de tests junto a su componente src y llenarlo con contenido.

En algunos casos, su equipo podría tener más estructuras de directorios bajo tests debido a la necesidad de agrupar diferentes conjuntos de pruebas en binarios individuales. Y en este caso, deberá crear un nuevo subdirectorio bajo tests .

Para ilustrar, aquí hay un esquema de directorio típico para componentes con una sola carpeta de tests :

 \
 <component source root>
  \-- Android.bp (component makefile)
  \-- AndroidTest.xml (test config file)
  \-- src (component source)
  |    \-- foo.cpp
  |    \-- ...
  \-- tests (test source root)
      \-- Android.bp (test makefile)
      \-- src (test source)
          \-- foo_test.cpp
          \-- ...
 

y aquí hay un esquema de directorio típico para componentes con múltiples directorios de origen de prueba:

 \
 <component source root>
  \-- Android.bp (component makefile)
  \-- AndroidTest.xml (test config file)
  \-- src (component source)
  |    \-- foo.cpp
  |    \-- ...
  \-- tests (test source root)
      \-- Android.bp (test makefile)
      \-- testFoo (sub test source root)
      |   \-- Android.bp (sub test makefile)
      |   \-- src (sub test source)
      |       \-- test_foo.cpp
      |       \-- ...
      \-- testBar
      |   \-- Android.bp
      |   \-- src
      |       \-- test_bar.cpp
      |       \-- ...
      \-- ...
 

Independientemente de la estructura, terminará poblando el directorio de tests o el subdirectorio recién creado con archivos similares a los que hay en el directorio native en el cambio de gerrit de muestra. Las secciones a continuación explicarán con más detalles cada archivo.

Código fuente

Vea la prueba Hello World Native para obtener un ejemplo.

El código fuente anotado se enumera a continuación:

 #include <gtest/gtest.h>
 

El archivo de encabezado incluye gtest. Tenga en cuenta que la dependencia del archivo de inclusión se resuelve automáticamente utilizando BUILD_NATIVE_TEST en el archivo MAKE

 #include <stdio.h>

TEST(HelloWorldTest, PrintHelloWorld) {
    printf("Hello, World!");
}
 

Las pruebas se escriben usando la macro TEST : el primer parámetro es el nombre del caso de prueba y el segundo es el nombre de la prueba; junto con el nombre binario de prueba, forman la jerarquía a continuación cuando se visualiza en el panel de resultados:

 <test binary 1>
| \-- <test case 1>
| |   \-- <test 1>
| |   \-- <test 2>
| |   \-- ...
| \-- <test case 2>
| |   \-- <test 1>
| |   \-- ...
| \-- ...
<test binary 2>
|
...
 

Para obtener más información sobre cómo escribir pruebas con gtest, consulte su documentación:

  • https://github.com/google/googletest/blob/master/googletest/docs/Primer.md

Archivo de configuración simple

Cada nuevo módulo de prueba debe tener un archivo de configuración para dirigir el sistema de compilación con metadatos del módulo, dependencias en tiempo de compilación e instrucciones de empaquetado. En la mayoría de los casos, la opción de archivo Blueprint basada en Soong es suficiente. Consulte Configuración de prueba simple para más detalles.

Archivo de configuración compleja

Para utilizar Trade Federation en su lugar, escriba un archivo de configuración de prueba para el arnés de prueba de Android, Trade Federation .

La configuración de prueba puede especificar opciones especiales de configuración del dispositivo y argumentos predeterminados para proporcionar la clase de prueba.

Construye y prueba localmente

Para los casos de uso más comunes, emplee Atest .

Para casos más complejos que requieren una personalización más pesada, siga las instrucciones de instrumentación .