如果您不熟悉 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
| \-- ...
\-- ...
不管结构如何，您最终都需要在 tests 目录或新建的子目录中填充类似示例 gerrit 更改中的 native 目录内的文件。下面几部分将进一步详细说明各个文件。
源代码
如需查看示例，请参阅 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 的 Blueprint 文件选项就足够了。如需了解详情，请参阅简单的测试配置。
复杂配置文件
如需改用 Trade Federation，请为 Android 的自动化测试框架 Trade Federation 编写测试配置文件。
测试配置可以指定特殊的设备设置选项和默认参数来提供测试类。
在本地构建和测试
对于最常见的用例，请使用 Atest。
对于需要更繁琐自定义设置的更复杂用例，请遵循插桩说明。