如果您不熟悉 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 。
對於需要大量定制的更複雜的情況，請遵循檢測說明。