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

Agregar un nuevo ejemplo de prueba nativa

Si es nuevo en el desarrollo de la plataforma Android, este ejemplo completo de cómo agregar una nueva prueba nativa desde cero puede resultarle útil para demostrar el flujo de trabajo típico involucrado. Además, si también está familiarizado con el marco GTEST para C ++, por favor revise la sede del proyecto GTEST de documentación adicional.

Esta guía utiliza la siguiente prueba como muestra:

Prueba nativa de Hello World

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

Decidir 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 de los equipos poseen un único repositorio de git, o comparten uno con otros equipos, pero tienen un subdirectorio dedicado que contiene el código fuente de los componentes.

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

Puesto que usted está agregando una nueva prueba de la marca, es probable que necesite para crear la tests directorio junto a su componente src , y rellenarla con el contenido.

En algunos casos, su equipo podría tener otras estructuras de directorios bajo tests debido a la necesidad de empaquetar diferentes suites de pruebas en los binarios individuales. Y en este caso, tendrá que crear un nuevo subdirectorio bajo tests .

Para ilustrar esto, aquí hay un esquema típico directorio para componentes con un único tests de carpetas:

\
 <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, que va a terminar poblando la tests directorio o subdirectorio recién creado con archivos similares a lo que está en native directorio en el cambio Gerrit muestra. Las secciones siguientes explicarán con más detalle cada archivo.

Código fuente

Vea la prueba Hello World nativo para un ejemplo.

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

#include <gtest/gtest.h>

El archivo de encabezado se incluye para gtest. Tenga en cuenta que la incluyen dependencia de archivo se resuelve automáticamente mediante el uso de BUILD_NATIVE_TEST en el makefile

#include <stdio.h>

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

gtests se escriben mediante el uso de TEST macro: el primer parámetro es el nombre de caso de prueba, y el segundo es nombre de la prueba; junto con el nombre binario de prueba, forman la jerarquía siguiente cuando se visualizan 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 basado en Soong es suficiente. Ver test sencillo para más detalles.

Archivo de configuración complejo

Para utilizar la Federación de Comercio en su lugar, escribir un archivo de configuración de prueba para la herramienta de prueba de Android, la Federación de Comercio .

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

Construya y pruebe localmente

Para la mayoría de los casos de uso común, emplean Atest .

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