[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-07-27 (世界標準時間)。"],[],[],null,["# Add new GoogleTests (GTests)\n\nIf you're new to Android platform development, you may find this complete\nexample of adding a brand new GTest binary (also sometimes called a \"native\"\ntest) from scratch useful to demonstrate the typical workflow involved. For\nadditional information on the GTest framework for\nC++, refer to the [GTest project\nsite](https://github.com/google/googletest) for additional documentation.\n\nThis guide uses the [Hello World GTest](https://android.googlesource.com/platform/platform_testing/+/android16-release/tests/example/native/)\nas an example. We recommend reading through the code to get a rough understanding\nof it before you continue.\n\nDecide on a source location\n---------------------------\n\nTypically your team will already have an established pattern of places to check\nin code, and places to add tests. Most team owns a single git repository, or\nshare one with other teams but have a dedicated sub directory that contains\ncomponent source code.\n\nAssuming the root location for your component source is at `\u003ccomponent source\nroot\u003e`, most components have `src` and `tests` folders under it, and some\nadditional files such as `Android.mk` (or broken up into additional `.bp`\nfiles).\n\nSince you are adding a brand new test, you'll probably need to create the\n`tests` directory next to your component `src`, and populate it with content.\n\nIn some cases, your team might have further directory structures under `tests`\ndue to the need to package different suites of tests into individual binaries.\nAnd in this case, you'll need to create a new sub directory under `tests`.\n\nTo illustrate, here's a typical directory outline for components with a single\n`tests` folder: \n\n \\\n \u003ccomponent source root\u003e\n \\-- Android.bp (component makefile)\n \\-- AndroidTest.xml (test config file)\n \\-- src (component source)\n | \\-- foo.cpp\n | \\-- ...\n \\-- tests (test source root)\n \\-- Android.bp (test makefile)\n \\-- src (test source)\n \\-- foo_test.cpp\n \\-- ...\n\nand here's a typical directory outline for components with multiple test source\ndirectories: \n\n \\\n \u003ccomponent source root\u003e\n \\-- Android.bp (component makefile)\n \\-- AndroidTest.xml (test config file)\n \\-- src (component source)\n | \\-- foo.cpp\n | \\-- ...\n \\-- tests (test source root)\n \\-- Android.bp (test makefile)\n \\-- testFoo (sub test source root)\n | \\-- Android.bp (sub test makefile)\n | \\-- src (sub test source)\n | \\-- test_foo.cpp\n | \\-- ...\n \\-- testBar\n | \\-- Android.bp\n | \\-- src\n | \\-- test_bar.cpp\n | \\-- ...\n \\-- ...\n\nRegardless of the structure, you'll end up populating the `tests` directory or\nthe newly created sub directory with files similar to what's in the `native`\ndirectory in the sample gerrit change. The sections below will explain in\nfurther details of each file.\n\nSource code\n-----------\n\nRefer to the [Hello World GTest](https://android.googlesource.com/platform/platform_testing/+/android16-release/tests/example/native/HelloWorldTest.cpp)\nfor an example.\n\nThe source code for that example is annotated here: \n\n #include \u003cgtest/gtest.h\u003e\n\nHeader file include for GTest. The include file dependency is automatically\nresolved by using `BUILD_NATIVE_TEST` in the makefile. \n\n #include \u003cstdio.h\u003e\n\n TEST(HelloWorldTest, PrintHelloWorld) {\n printf(\"Hello, World!\");\n }\n\nGTests are written using the `TEST` macro: the first parameter is the test case\nname, and the second is the test name. Along with test binary name, they form the\nfollowing hierarchy in the result dashboard: \n\n \u003ctest binary 1\u003e\n | \\-- \u003ctest case 1\u003e\n | | \\-- \u003ctest 1\u003e\n | | \\-- \u003ctest 2\u003e\n | | \\-- ...\n | \\-- \u003ctest case 2\u003e\n | | \\-- \u003ctest 1\u003e\n | | \\-- ...\n | \\-- ...\n \u003ctest binary 2\u003e\n |\n ...\n\nFor more information on writing tests with GTest, refer to [the GTest documentation](https://github.com/google/googletest/blob/main/docs/primer.md)\n\nSimple configuration file\n-------------------------\n\nEach new test module must have a configuration file to direct\nthe build system with module metadata, compile-time dependencies and packaging\ninstructions. In most cases, the Soong-based, Blueprint file option is\nsufficient. See [Simple Test Configuration](/docs/core/tests/development/blueprints) for details.\n\nComplex configuration file\n--------------------------\n\n| **Important:** The instructions in this section are needed only for CTS tests or those that require special setup, such as disabling Bluetooth or collecting sample data. All other cases can be covered through the [Simple Test Configuration](/docs/core/tests/development/blueprints). See the [Complex Test Configuration](/docs/core/tests/development/test-config) for more details applicable to this section.\n\nTo use Trade Federation instead, write a test configuration\nfile for Android's test harness, [Trade Federation](/docs/core/tests/tradefed).\n\nThe test configuration can specify special device setup options and default\narguments to supply the test class.\n\nBuild and test locally\n----------------------\n\nFor the most common use cases, employ\n[Atest](/docs/core/tests/development/atest).\n\nFor more complex cases requiring heavier customization, follow the\n[instrumentation instructions](/docs/core/tests/development/instrumentation)."]]