Audio Hal VTS: Refactor ASSERT_RESULT helper
ASSERT_INVALID_ARGUMENTS was a macro that asserted that a given Result
or Return contained INVALID_ARGUMENT. The problem was that a result can
have lots of other values like INVALID_STATE or NOT_SUPPORTED.
Additionally not all test expect only one possible result.
Introduce two overload of ASSERT_RESULT()
The first one takes an expected Result value and compare it to the
obtained one.
The second take a list and expect the obtained one to be in this list.
Test: run the test on target
Bug: 34170075
Change-Id: I798729f27f723c98292610bfb43dbdb2724ec2ca
Signed-off-by: Kevin Rocard <krocard@google.com>
diff --git a/audio/2.0/vts/functional/AudioPrimaryHidlHalTest.cpp b/audio/2.0/vts/functional/AudioPrimaryHidlHalTest.cpp
index 74a72aa..30f5b30 100644
--- a/audio/2.0/vts/functional/AudioPrimaryHidlHalTest.cpp
+++ b/audio/2.0/vts/functional/AudioPrimaryHidlHalTest.cpp
@@ -217,7 +217,7 @@
for (Property invalidValue : invalidValues) {
SCOPED_TRACE("Try to set " + propertyName + " with the invalid value " +
testing::PrintToString(invalidValue));
- EXPECT_INVALID_ARGUMENTS((device.get()->*setter)(invalidValue));
+ EXPECT_RESULT(Result::INVALID_ARGUMENTS, (device.get()->*setter)(invalidValue));
}
ASSERT_OK((device.get()->*setter)(initialValue)); // restore initial value
@@ -714,7 +714,7 @@
SCOPED_TRACE("volume=" + to_string(volume));
// FIXME: NAN should never be accepted
// FIXME: Missing api doc. What should the impl do if the volume is outside [0,1] ?
- ASSERT_INVALID_ARGUMENTS(device->setVoiceVolume(volume));
+ ASSERT_RESULT(Result::INVALID_ARGUMENTS, device->setVoiceVolume(volume));
}
}
@@ -728,7 +728,7 @@
}
// FIXME: Missing api doc. What should the impl do if the mode is invalid ?
- ASSERT_INVALID_ARGUMENTS(device->setMode(AudioMode::INVALID));
+ ASSERT_RESULT(Result::INVALID_ARGUMENTS, device->setMode(AudioMode::INVALID));
}