Si es la primera vez que desarrollas para la plataforma de Android, este ejemplo completo de cómo agregar un nuevo archivo binario de GTest (también llamado a veces prueba "nativa") desde cero puede ser útil para demostrar el flujo de trabajo típico involucrado. Para obtener más información sobre el framework de GTest para C++, consulta el sitio del proyecto de GTest para obtener documentación adicional.
En esta guía, se usa el Hello World GTest como ejemplo. Te recomendamos que leas el código para comprenderlo de forma general antes de continuar.
Decide una ubicación de origen
Por lo general, tu 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 son propietarios de un solo repositorio de Git o comparten uno con otros equipos, pero tienen un subdirectorio exclusivo que contiene el código fuente del componente.
Si suponemos que la ubicación raíz del código fuente de tu componente es <component source
root>, la mayoría de los componentes tienen carpetas src y tests debajo de ella, y algunos archivos adicionales, como Android.mk (o divididos en archivos .bp adicionales).
Como agregarás una prueba completamente nueva, es probable que debas crear el directorio tests junto a tu componente src y completarlo con contenido.
En algunos casos, es posible que tu equipo tenga más estructuras de directorios en tests debido a la necesidad de empaquetar diferentes conjuntos de pruebas en archivos binarios individuales.
En este caso, deberás crear un subdirectorio nuevo en tests.
Para ilustrarlo, aquí se muestra un esquema de directorio típico para componentes con una sola carpeta 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í tienes un esquema de directorio típico para componentes con varios directorios de fuentes 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ás propagando el directorio tests o el subdirectorio recién creado con archivos similares a los que se encuentran en el directorio native en el cambio de Gerrit de muestra. En las siguientes secciones, se explicará cada archivo con más detalle.
Código fuente
Consulta el GTest de Hello World para ver un ejemplo.
El código fuente de ese ejemplo se anota aquí:
#include <gtest/gtest.h>
Se incluye el archivo de encabezado para GTest. La dependencia del archivo de inclusión se resuelve automáticamente con BUILD_NATIVE_TEST en el archivo makefile.
#include <stdio.h>
TEST(HelloWorldTest, PrintHelloWorld) {
printf("Hello, World!");
}
Las GTests se escriben con 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 del archivo binario de prueba, forman la siguiente jerarquía 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, consulta la documentación de GTest.
Archivo de configuración simple
Cada módulo de prueba nuevo debe tener un archivo de configuración para dirigir el sistema de compilación con metadatos del módulo, instrucciones de empaquetado y dependencias de tiempo de compilación. En la mayoría de los casos, la opción de archivo Blueprint basado en Soong es suficiente. Consulta Configuración de prueba simple para obtener más detalles.
Archivo de configuración complejo
Para usar Trade Federation, escribe un archivo de configuración de prueba para el arnés de prueba de Android, Trade Federation.
La configuración de la prueba puede especificar opciones especiales de configuración del dispositivo y argumentos predeterminados para proporcionar la clase de prueba.
Compila y prueba de forma local
Para los casos de uso más comunes, emplea Atest.
Para casos más complejos que requieren una mayor personalización, sigue las instrucciones de instrumentación.