tree af89502194693f6dcd80a6b6a7a1d5a9f4d2e90a
parent 58c52f2ef6bc2f9fc87f258f7e6f720607d88168
author Martin Puryear <mpuryear@google.com> 1550188684 -0800
committer CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> 1550266788 +0000

[media][tests] Eliminate flaky audio_fidl_tests behavior

By performing the initial connect-to-Audio-service in a
global (programwide) test set-up phase, we ensure that audio
components have been loaded and are available for normal
operation before testing starts. Today, when a test runner/
environment is highly loaded, we run a chance that by the
time audio_fidl_tests starts running tests, Amber may not
yet have finished loading the Audio and AudioCore components
onto the target machine. When this wait bleeds over into the
first test cases, their initial assumptions may be violated
(they may not be resilient to an initial delay of 100
milliseconds before getting their first response).

Over time these test cases will be rewritten to eliminate
any remaining aspects of "Success == No Response", so that
they can essentially use infinite waits. These places in the
code have been marked by TODO. Between now and that day,
this is an effective and reasonable solution.

In addition to establishing the SetUp/TearDown of the
overall test environment, this CL also introduces one
instance of TestSuite (class) level SetUp/TearDown, in the
AudioRendererSync test set. If in the future the execution
of test programs is sharded to different machines, we can
still expect each TestSuite to be executed on a single
machine; this type of class-level initial setup is how we
would need to solve the problem at that point.

BUG: FLK-47 #done
TEST: build, CQ, overnight loop on NUC, arm64 QEMU and x64 QEMU

Change-Id: I345e20f5377eaa95a7d6b743c66cd670e7379090