Espresso test case to control loopback call

webrtc/examples/BUILD.gn

Index: webrtc/examples/BUILD.gn
diff --git a/webrtc/examples/BUILD.gn b/webrtc/examples/BUILD.gn
index e6b73f017d2def3ee4fec0ff3d73e0591b121782..8463285fadc3775d0d9ace0c8a558d3cd18dd818 100644
--- a/webrtc/examples/BUILD.gn
+++ b/webrtc/examples/BUILD.gn
@@ -107,6 +107,7 @@ if (is_android) {
     android_manifest = "androidtests/AndroidManifest.xml"
 
     java_files = [
+      "androidtests/src/org/appspot/apprtc/test/ConnectActivityStubbedInputOutputTest.java",

[kjellander_webrtc, 2016/12/19 11:26:25]

I remember we talked about having a Python script wrap around this test
execution, so it can:
1) download the video quality toolchain resources
2) run the test
3) pull the video file
4) run compare_videos.py 
etc.

For that to happen (I assume in a follow-up CL), I think it's better we create a
separate target for ConnectActivityStubbedInputOutputTest.java than adding it to
AppRTCMobileTest. It doesn't really add much value being run on the bots as it
is now anyway.

       "androidtests/src/org/appspot/apprtc/test/FileVideoCapturerTest.java",
       "androidtests/src/org/appspot/apprtc/test/PeerConnectionClientTest.java",
       "androidtests/src/org/appspot/apprtc/test/VideoFileRendererTest.java",
@@ -116,6 +117,11 @@ if (is_android) {
 
     deps = [
       ":AppRTCMobile_javalib",
+      "//third_party/android_support_test_runner:rules_java",
+      "//third_party/android_support_test_runner:runner_java",
+      "//third_party/espresso:espresso_all_java",
+      "//third_party/hamcrest:hamcrest_java",
+      "//third_party/junit",
       "//webrtc/sdk/android:libjingle_peerconnection_java",
     ]