Fix rare audioLevel flake in RTCStatsIntegrationTest.
The integration test sets up a loopback call, verifies media is flowing,
and then asserts which metrics should be available.
One of the things it asserted was that audioLevel is positive. This
could flake in rare circumstances because audioLevel requires a certain
number of samples to have been received before it is updated or else it
would have its default value zero.
This test is a broad asserting things about 150+ metrics; it's not worth
adding a dependency on the "implementation detail" about how long you
have to wait before this specific metric is non-zero. The fix for the
flake is to only require the metric to have been set, but zero is also
an acceptable value.
We don't lose much test coverage; we're still asserting that other
audio metrics originating from the same class have positive values.
Bug: webrtc:10962
Change-Id: I5def9193da7150492d89ea62031858bac5c41646
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/152821
Reviewed-by: Yves Gerey <yvesg@google.com>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29179}
diff --git a/pc/rtc_stats_integrationtest.cc b/pc/rtc_stats_integrationtest.cc
index 29f0651..7cb3028 100644
--- a/pc/rtc_stats_integrationtest.cc
+++ b/pc/rtc_stats_integrationtest.cc
@@ -928,7 +928,10 @@
bool VerifyRTCAudioSourceStats(const RTCAudioSourceStats& audio_source) {
RTCStatsVerifier verifier(report_, &audio_source);
VerifyRTCMediaSourceStats(audio_source, &verifier);
- verifier.TestMemberIsPositive<double>(audio_source.audio_level);
+ // Audio level, unlike audio energy, only gets updated at a certain
+ // frequency, so we don't require that one to be positive to avoid a race
+ // (https://crbug.com/webrtc/10962).
+ verifier.TestMemberIsNonNegative<double>(audio_source.audio_level);
verifier.TestMemberIsPositive<double>(audio_source.total_audio_energy);
verifier.TestMemberIsPositive<double>(audio_source.total_samples_duration);
return verifier.ExpectAllMembersSuccessfullyTested();