[llvm] [offload] add parameterized unit tests (PR #209115)

[via llvm-commits]

================
@@ -204,46 +207,68 @@ struct OffloadDeviceTest
     return Backend;
   }
 
+  const OffloadParam<T> &getParamTuple() const { return this->GetParam(); }
+
+  const T &getTestParam() { return std::get<1>(getParamTuple()); }
+
   ol_device_handle_t Device = nullptr;
 };
 
-struct OffloadPlatformTest : OffloadDeviceTest {
+// In order to avoid code duplication, the unparameterized versions of fixtures
+// are aliases for parameterized fixtures, with `int` type chosen arbitrarily as
+// an ignored parameter type. The single mock parameter of value `0` is combined
+// with the devices in the provided macros, yielding tuples
+// `std::tuple<TestEnvironment::Device, int>`. The hidden `int` parameter is not
+// used, but it enables users to instantiate unparameterized tests without the
+// knowledge about the details related to the implementation of fixtures.
+// Moreover, it allows for modifying only one version of the fixture, without
+// the need to also change the other version: either parameterized or
+// unparameterized.
+using OffloadDeviceTest = OffloadDeviceTestWithParam<int>;
----------------
EuphoricThinking wrote:

I am also concerned that the aliasing of unparametrized tests affects readability, but my other concern is the maintainability of other solutions I can come up with.

There was already hidden parametrization in tests: 
`struct OffloadDeviceTest
    : OffloadTest,
      ::testing::WithParamInterface<TestEnvironment::Device> {...};` 
(see [here](https://github.com/llvm/llvm-project/blob/652e04312e8c5f4fc90ac16be494c3562c111ab9/offload/unittests/OffloadAPI/common/Fixtures.hpp#L183-L185)). As a cleaner approach, I would consider leaving the main path of inheritance from `OffloadDeviceTest`, with branching off for parametrized versions. The implementation I would imagine as similar to: 

`struct FooTestWithParam: FooTest,  ::testing::WithParamInterface<T> 
{
// handle only parameters, setup left  for FooTest::SetUp()
};`

Is inheriting twice from the same class (`::testing::WithParamInterface<TestEnvironment::Device>`) a better option for you? I haven't tested it, but it seems to be possible.

The previous version of this patch duplicated unparametrized code in the parametrized fixture. I think aliasing eliminates the risk of failing to introduce a change in the symmetrical parametrized version, if the modifications are needed in the unparametrized one.

https://github.com/llvm/llvm-project/pull/209115