Od 27 marca 2025 r. zalecamy używanie android-latest-release
zamiast aosp-main
do kompilowania i wspołtworzenia AOSP. Więcej informacji znajdziesz w artykule o zmianach w AOSP.
Test GTest z parametrami na potrzeby testowania HAL
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
W przypadku interfejsu HAL może być wiele implementacji. Aby przetestować każdą instancję implementacji HAL, standardowym sposobem jest napisanie testu GTest z parametrami wartości.
Podstawowa konfiguracja testu
Test GTest musi dziedziczyć po klasie podstawowej testing::TestWithParam
, której parametrem jest nazwa każdej instancji. W metodzie SetUp
usługa może zostać uruchomiona na podstawie nazwy instancji, jak pokazano w tym fragmencie kodu.
// The main test class for the USB hidl HAL
class UsbHidlTest : public testing::TestWithParam<std::string> {
virtual void SetUp() override {
usb = IUsb::getService(GetParam());
ASSERT_NE(usb, nullptr);
...
}
W przypadku każdej metody testu użyj makra TEST_P
, jak pokazano w tym przykładzie:
TEST_P(UsbHidlTest, setCallback) {
...
}
Utwórz instancję pakietu za pomocą makra INSTANTIATE_TEST_SUITE_P
, jak pokazano w tym przykładzie:
INSTANTIATE_TEST_SUITE_P(
PerInstance, UsbHidlTest,
testing::ValuesIn(android::hardware::getAllHalInstanceNames(IUsb::descriptor)),
android::hardware::PrintInstanceNameToString);
Argumenty:
InstantiationName
, co może być dowolnym elementem pasującym do testu. PerInstance
to typowa nazwa.
Nazwa klasy testu.
Kolekcja nazw instancji, którą można pobrać z wbudowanej metody, na przykład getAllHalInstanceNames
.
Metoda drukowania nazwy metody testu.
PrintInstanceNameToString
to wbudowana nazwa, której możesz użyć do skompilowania nazwy testu na podstawie nazwy instancji i metody testu.
GTest obsługuje tuple w przypadku testów z parametrami wartościowymi. Jeśli test HAL wymaga testowania z użyciem wielu danych wejściowych (np. test z wieloma interfejsami), możesz napisać test GTest z parametrem testu tuple
. Pełny kod znajdziesz w pliku VtsHalGraphicsMapperV2_1TargetTest
.
W porównaniu z testem GTest z jednym parametrem testowym ten test musi używać parametru testowego tuple
, jak pokazano w tym przykładzie:
class GraphicsMapperHidlTest
: public ::testing::TestWithParam<std::tuple<std::string, std::string>> {
protected:
void SetUp() override {
ASSERT_NO_FATAL_FAILURE(mGralloc = std::make_unique<Gralloc>(std::get<0>(GetParam()),
std::get<1>(GetParam())));
…
}
Jeśli potrzebujesz bardziej złożonych parametrów, zalecamy użycie struktury i funkcji niestandardowych ToString
GTest.
Aby utworzyć instancję pakietu testów, użyj makra INSTANTIATE\_TEST\_CASE\_P
z 2 modyfikacjami:
- Trzeci argument to zbiór tupla (w odróżnieniu od zbioru ciągów znaków w przypadku podstawowym).
- Metoda kompilowania nazwy testu musi obsługiwać
tuple
. Możesz użyć wbudowanej metody PrintInstanceTupleNameToString
, która obsługuje tuple ciągów znaków, jak w tym przykładzie:
INSTANTIATE_TEST_CASE_P(
PerInstance, GraphicsMapperHidlTest,
testing::Combine(
testing::ValuesIn(
android::hardware::getAllHalInstanceNames(IAllocator::descriptor)),
testing::ValuesIn(android::hardware::getAllHalInstanceNames(IMapper::descriptor))),
android::hardware::PrintInstanceTupleNameToString<>);
Treść strony i umieszczone na niej fragmenty kodu podlegają licencjom opisanym w Licencji na treści. Java i OpenJDK są znakami towarowymi lub zastrzeżonymi znakami towarowymi należącymi do firmy Oracle lub jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2025-07-27 UTC.
[[["Łatwo zrozumieć","easyToUnderstand","thumb-up"],["Rozwiązało to mój problem","solvedMyProblem","thumb-up"],["Inne","otherUp","thumb-up"]],[["Brak potrzebnych mi informacji","missingTheInformationINeed","thumb-down"],["Zbyt skomplikowane / zbyt wiele czynności do wykonania","tooComplicatedTooManySteps","thumb-down"],["Nieaktualne treści","outOfDate","thumb-down"],["Problem z tłumaczeniem","translationIssue","thumb-down"],["Problem z przykładami/kodem","samplesCodeIssue","thumb-down"],["Inne","otherDown","thumb-down"]],["Ostatnia aktualizacja: 2025-07-27 UTC."],[],[],null,["# Parameterized GTest for HAL testing\n\nFor a HAL interface, there might be multiple implementations. To test each\ninstance for a HAL implementation, the standard way is to write\na [value-parameterized GTest](https://github.com/google/googletest/blob/main/docs/advanced.md#value-parameterized-tests).\n\nBasic test setup\n----------------\n\nThe GTest must inherit the base class `testing::TestWithParam`, of\nwhich the parameter is the name of each instance. In the\n`SetUp` method, the service can be instantiated based on the\ninstance name, as shown in the following code snippet. \n\n // The main test class for the USB hidl HAL\n class UsbHidlTest : public testing::TestWithParam\u003cstd::string\u003e {\n\n virtual void SetUp() override {\n usb = IUsb::getService(GetParam());\n ASSERT_NE(usb, nullptr);\n ...\n }\n\nFor each test method, use the macro `TEST_P` as shown in the following example: \n\n TEST_P(UsbHidlTest, setCallback) {\n ...\n }\n\nInstantiate the suite with\nmacro `INSTANTIATE_TEST_SUITE_P`, as shown in the following example: \n\n INSTANTIATE_TEST_SUITE_P(\n PerInstance, UsbHidlTest,\n testing::ValuesIn(android::hardware::getAllHalInstanceNames(IUsb::descriptor)),\n android::hardware::PrintInstanceNameToString);\n\nThe arguments are:\n\n1. `InstantiationName`, which can be anything that\n matches your test. `PerInstance` is a common name.\n\n2. The test class name.\n\n3. A collection of instance names, which can\n be retrieved from the built-in method, for example,\n `getAllHalInstanceNames`.\n\n4. The method to print the test method name.\n `PrintInstanceNameToString` is a built-in name you can use to\n compile a test name based on the instance name and test method name.\n\nTest with multiple inputs\n-------------------------\n\nGTest supports tuples for value-parameterized tests. When a\nHAL test requires testing with multiple inputs (for example, a test with\nmultiple interfaces), you can write a GTest with `tuple` as the\ntest parameter. The complete\ncode can be found in [`VtsHalGraphicsMapperV2_1TargetTest`](https://cs.android.com/android/platform/superproject/+/android-latest-release:hardware/interfaces/graphics/mapper/2.1/vts/functional/VtsHalGraphicsMapperV2_1TargetTest.cpp).\n\nCompared to the GTest with a single test parameter, this test needs to use\n`tuple` as the test parameter as shown in the following example: \n\n class GraphicsMapperHidlTest\n : public ::testing::TestWithParam\u003cstd::tuple\u003cstd::string, std::string\u003e\u003e {\n protected:\n void SetUp() override {\n ASSERT_NO_FATAL_FAILURE(mGralloc = std::make_unique\u003cGralloc\u003e(std::get\u003c0\u003e(GetParam()),\n std::get\u003c1\u003e(GetParam())));\n ...\n }\n\nIf more complicated parameters are needed, it's recommended to use a\nstructure and custom GTest `ToString` functions.\n\nTo instantiate the test suite, the macro `INSTANTIATE\\_TEST\\_CASE\\_P` is also\nused, with two differences:\n\n- The third argument is a collection of tuples (versus a collection of strings in the basic case).\n- The method to compile a test name needs to support `tuple`. You can use the built-in method `PrintInstanceTupleNameToString`, which can handle tuples of strings, as shown in the following example:\n\n INSTANTIATE_TEST_CASE_P(\n PerInstance, GraphicsMapperHidlTest,\n testing::Combine(\n testing::ValuesIn(\n android::hardware::getAllHalInstanceNames(IAllocator::descriptor)),\n testing::ValuesIn(android::hardware::getAllHalInstanceNames(IMapper::descriptor))),\n android::hardware::PrintInstanceTupleNameToString\u003c\u003e);"]]