Si eres nuevo en el desarrollo de la plataforma de Android, es posible que te encuentres completo ejemplo de agregar un objeto binario de GTest nuevo (también a veces llamado “nativo” test) desde cero útiles para demostrar el flujo de trabajo típico involucrado. Para información adicional sobre el framework de GTest para C++, consulta el proyecto GTest sitio para obtener documentación adicional.
En esta guía, se usa la prueba GTest de Hello World como ejemplo. Te recomendamos que leas el código para obtener una comprensión aproximada. antes de continuar.
Elige una ubicación de origen
Normalmente, tu equipo ya tendrá un patrón establecido de lugares para comprobar en código y lugares donde agregar pruebas. La mayoría de los equipos es propietario de un solo repositorio de Git. comparten uno con otros equipos, pero tienen un subdirectorio dedicado que contiene el código fuente del componente.
Si suponemos que la ubicación raíz de tu fuente de componentes es <component source
root>, la mayoría de los componentes tienen carpetas src y tests en ella, y algunos componentes
archivos adicionales, como Android.mk (o divididos en .bp adicionales
archivos).
Dado que agregarás una prueba nueva, probablemente debas crear
tests junto al componente src y propágalo con contenido.
En algunos casos, tu equipo puede tener estructuras de directorios adicionales en tests.
debido a la necesidad de empaquetar
distintos conjuntos de pruebas en binarios individuales.
En este caso, deberás crear un nuevo subdirectorio en tests.
A modo de ejemplo, este es 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
\-- ...
Este es un esquema de directorio típico para componentes con varias fuentes de prueba. directorios:
\
<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 lo que hay en native.
en el cambio de Gerrit de muestra. En las siguientes secciones, se explicará
más detalles de cada archivo.
Código fuente
Consulta la Prueba GTest de Hello World para ver un ejemplo.
El código fuente para ese ejemplo se anota aquí:
#include <gtest/gtest.h>
Archivo de encabezado incluido para GTest. La dependencia del archivo de inclusión se convierte automáticamente
se resuelve con BUILD_NATIVE_TEST en el archivo make.
#include <stdio.h>
TEST(HelloWorldTest, PrintHelloWorld) {
printf("Hello, World!");
}
Las GTests se escriben con la macro TEST: el primer parámetro es el caso de prueba.
y el segundo es el nombre de la prueba. Junto con el nombre del objeto binario de prueba, forman el
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 de módulos, dependencias de tiempo de compilación y empaquetado instrucciones. En la mayoría de los casos, la opción de archivo de Blueprint basado en Soong es suficientes. Consulta Configuración de prueba simple para obtener más detalles.
Archivo de configuración complejo
Para usar la Federación de Comercio, escribe una configuración de prueba archivo del agente de prueba de Android, la Federación de Comercio.
La configuración de prueba puede especificar opciones especiales de configuración de dispositivos para proporcionar la clase de prueba.
Compila y prueba de forma local
Para los casos de uso más comunes, emplea Atest (Atest).
Para casos más complejos que requieren una mayor personalización, sigue las instrucciones de instrumentación.