Si es nuevo en el desarrollo de la plataforma Android, puede encontrar útil este ejemplo completo de agregar un nuevo binario GTest (también llamado a veces prueba "nativa") desde cero para demostrar el flujo de trabajo típico involucrado. Para obtener información adicional sobre el marco GTest para C++, consulte el sitio del proyecto GTest para obtener documentación adicional.
Esta guía usa el Hello World GTest como ejemplo. Recomendamos leer el código para obtener una comprensió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 verificar el código y lugares para agregar pruebas. La mayoría de los equipos poseen un solo repositorio de git, o comparten uno con otros equipos, pero tienen un subdirectorio dedicado que contiene el código fuente del componente.
Suponiendo que la ubicación raíz de la fuente de su componente sea <component source root> , la mayoría de los componentes tienen carpetas src y tests debajo, y algunos archivos adicionales como Android.mk (o divididos en archivos .bp adicionales).
Dado que está agregando una nueva prueba, probablemente necesitará crear el directorio de tests al lado de su componente src y llenarlo con contenido.
En algunos casos, su equipo puede tener más estructuras de directorios bajo tests debido a la necesidad de empaquetar diferentes conjuntos de pruebas en binarios individuales. Y en este caso, deberá crear un nuevo subdirectorio en 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 en más detalles de cada archivo.
Código fuente
Consulte Hello World GTest para ver un ejemplo.
El código fuente de ese ejemplo está anotado aquí:
#include <gtest/gtest.h>
Archivo de encabezado incluido para GTest. La dependencia del archivo de inclusión se resuelve automáticamente mediante BUILD_NATIVE_TEST en el archivo MAKE.
#include <stdio.h>
TEST(HelloWorldTest, PrintHelloWorld) {
printf("Hello, World!");
}
Las pruebas GT se escriben utilizando 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 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, consulte la documentación de GTest
Archivo de configuración sencillo
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 obtener más detalles.
Archivo de configuración complejo
Para usar 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 de configuración de dispositivos especiales y argumentos predeterminados para proporcionar la clase de prueba.
Cree y pruebe localmente
Para los casos de uso más comunes, emplee Atest .
Para casos más complejos que requieran una mayor personalización, siga las instrucciones de instrumentación .