Repeating Android Espresso Tests efficiently

Jim Hu
Jim Hu
Aug 23, 2017 · 2 min read

How to run a specific Espresso test repeatedly efficiently on Android to test intermittent issues using adb

The Problem — Intermittent issues

This best practice to handle intermittent issues that are failing Espresso tests, is to create IdlingResources. But before and after that, you need to pinpoint the issue and verify the fix.

You can do it several ways, with different caveats:

  • Sure you can run it a few times with your finger on the “Run” button, (and be smart enough to remove the Make and save time)
Remove this from the “Run/Debug Config” to skip building/installing the test Apk every run
  • Or…you can write scripts to run them through the terminal.

The Script — Getting into the Hall of Fame (of testing)

See: https://developer.android.com/studio/test/command-line

But my finger is weak, my patience is not thick enough to sit through the number of tests required for statistical significance, which would be likely >100 times… 😵
We need to script it!

There’s 2 ways to trigger a specific Instrumented Espresso test method from the terminal/script

Through Gradle tasks

It looks something like this

./gradlew :main:CoolApp:connectedAndroidTest -Pandroid.testInstrumentationRunnerArguments.class=com.coolcompany.coolapp.testpackage.SomeTestClass#testThisTestMethod

But there’s no way to disable Gradle build, so every test requires going through the Gradle process again, which for us would mean >5mins each for our gigantic build. It’ll take almost half a day just to run them 100 times, which is waaaaay too long to pass as a coffee break ☕️.

Through the “am instrument” Command

Tests are actually bundled in a separate Apk from your main app, and can be triggered directly through the adb shell after installation.

It looks something like this

adb shell am instrument -w -e class com.coolcompany.coolapp.testpackage.SomeTestClass#testThisTestMethod com.coolcompany.coolapp.debug.test/
android.support.test.runner.AndroidJUnitRunner

Ok cool! Wait… what’s that mumble jumble thing about the whatClass/whatchamacallitRunner? Which one should I be using?

You can figure it out digging through you code base, or… just run this after running the test from Gradle at least once:

adb shell pm list instrumentation

You’ll likely see something like this:

instrumentation:com.coolcompany.coolapp.debug.test/
android.support.test.runner.AndroidJUnitRunner (target=com.coolcompany.coolapp.debug)
  • Note: AndroidJUnitRunner is the default runner, there’s chances that you may have it inherited and overridden, but it’ll be reflected here 🎉

Finally

A script that runs a test 100 times would look like this:

Happy testing!

)

Jim Hu

Written by

Jim Hu

Android@Workday

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade