如果您不熟悉 Android 平台开发，您可能会发现这个从头开始添加全新 GTest 二进制文件（有时也称为“本机”测试）的完整示例对于演示所涉及的典型工作流程很有用。有关 C++ 的 GTest 框架的更多信息，请参阅GTest 项目站点以获取更多文档。
本指南以Hello World GTest为例。我们建议您在继续之前通读代码以大致了解它。
确定源位置
通常，您的团队已经有一个既定的模式来检查代码和添加测试的地方。大多数团队拥有一个 git 存储库，或者与其他团队共享一个，但有一个包含组件源代码的专用子目录。
假设您的组件源的根位置在<component source root> ，大多数组件在其下都有src和tests文件夹，以及一些额外的文件，例如Android.mk （或分解为额外.bp文件）。
由于您要添加一个全新的测试，您可能需要在组件src旁边创建tests目录，并使用内容填充它。
在某些情况下，由于需要将不同的测试套件打包到单独的二进制文件中，您的团队可能在tests中还有更多的目录结构。在这种情况下，您需要在tests下创建一个新的子目录。
为了说明，这里是具有单个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
\-- ...
这是具有多个测试源目录的组件的典型目录大纲：
\
<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
| \-- ...
\-- ...
无论结构如何，您最终都会使用类似于示例 gerrit 更改中本native目录中的文件的文件填充tests目录或新创建的子目录。以下部分将详细解释每个文件。
源代码
有关示例，请参阅Hello World GTest 。
该示例的源代码在此处注释：
#include <gtest/gtest.h>
包含 GTest 的头文件。在 makefile 中使用BUILD_NATIVE_TEST会自动解析包含文件的依赖关系。
#include <stdio.h>
TEST(HelloWorldTest, PrintHelloWorld) {
printf("Hello, World!");
}
GTest 是使用TEST宏编写的：第一个参数是测试用例名称，第二个是测试名称。与测试二进制名称一起，它们在结果仪表板中形成以下层次结构：
<test binary 1>
| \-- <test case 1>
| | \-- <test 1>
| | \-- <test 2>
| | \-- ...
| \-- <test case 2>
| | \-- <test 1>
| | \-- ...
| \-- ...
<test binary 2>
|
...
有关使用 GTest 编写测试的更多信息，请参阅GTest 文档
简单的配置文件
每个新的测试模块都必须有一个配置文件，以使用模块元数据、编译时依赖项和打包指令来指导构建系统。在大多数情况下，基于 Soong 的蓝图文件选项就足够了。有关详细信息，请参阅简单测试配置。
复杂的配置文件
要改用 Trade Federation，请为 Android 的测试工具Trade Federation编写一个测试配置文件。
测试配置可以指定特殊的设备设置选项和默认参数来提供测试类。
在本地构建和测试
对于最常见的用例，请使用Atest 。
对于需要大量定制的更复杂的情况，请遵循检测说明。