Android · Testing

Testing Android Apps: The Test Pyramid, JUnit, UI Automation and TDD

Every Android team says it wants tests. Fewer can say which tests to write, where they should run, and which of the many libraries to pick. This guide walks the whole map in order: the test pyramid, JUnit 4 and 5, the libraries that sit around JUnit, instrumentation and UI tests, Appium and other UI automation tools, how to keep UI tests from being flaky, and what test-driven development (TDD) really gives you. Every idea has a small Kotlin example.

1. Why test at all

A test is a small program that checks your program. You run it, it either passes or fails, and nobody has to look at the screen. That one property is why tests are worth the effort: they turn “I think this still works” into “I know this still works”, in seconds, every time you change something.

Good tests give you four things. They catch regressions, which are bugs in behaviour that used to work. They let you refactor with confidence, because a red test tells you immediately when a cleanup broke something. They act as executable documentation of what the code is meant to do. And they shorten code review, because a reviewer can read the tests to see the intent.

Tests are also code, and code has a cost. A slow, brittle test suite is worse than none, because people stop trusting it and start ignoring red builds. The goal is never “100% coverage”. The goal is the most confidence per minute of writing, running and maintaining.

2. The test pyramid

The test pyramid is a picture of how many tests to write at each level. Small, fast tests that check one thing go at the bottom, and there should be many of them. Big, slow tests that drive the whole app go at the top, and there should be few.

Why a pyramid and not a rectangle

• Feedback time. A thousand unit tests can finish before you let go of the save shortcut. A thousand UI tests take hours, so people run them rarely, and bugs live longer.
• Pinpointing. When a unit test fails, it names the class. When an end-to-end test fails, the cause could be the UI, the network, the emulator, the test data or the test itself.
• Cost. High-level tests break whenever a button moves. Low-level tests break only when the behaviour they describe changes.
• Combinations. A form with five fields and three states per field has 243 combinations. Testing each one through the UI is absurd. Testing the validation logic with unit tests is trivial.

A common rule of thumb, often credited to Google’s testing guidance, is roughly 70% small, 20% medium and 10% large tests. Treat it as a starting point, not a quota.

The shapes to avoid and the other shapes

• The ice-cream cone. The pyramid upside down: lots of manual and UI testing, a few unit tests. It is slow, expensive and fragile. Many teams end up here by accident because UI tests are the easiest to start with.
• The testing trophy (popular in web teams) puts the most value on integration tests. The honeycomb (popular for microservices) does the same. Both share the idea that the right shape depends on your system. For Android apps with lots of logic in ViewModels and use cases, the pyramid still fits well.

3. Where Android tests live: local and instrumented

Android splits tests into two homes, and picking the right one is the first real decision.

Google also names tests by size: small (one class, no I/O, runs anywhere), medium (a few components together) and large (the whole app, end to end). The annotations @SmallTest, @MediumTest and @LargeTest from androidx.test.filters let you run a size on its own. They are the pyramid’s three layers with different names.

The “not mocked” error

Local tests compile against a stripped android.jar whose methods throw. If your logic calls Log.d(...) or TextUtils.isEmpty(...), the test fails with “Method ... not mocked”. You have three ways out:

1. Keep Android out of your logic. This is the best fix: use plain Kotlin types in ViewModels, use cases and mappers, and wrap the framework behind an interface.
2. Use Robolectric, which supplies a working simulation of the framework on the JVM.
3. Move the test to androidTest and run it on a device.

4. Unit tests with JUnit 4 and 5

JUnit is the standard test framework for Java and Kotlin. It finds methods marked @Test, runs each one, and reports pass or fail. Every other tool in this post builds on it or plugs into it.

The anatomy of a test: Arrange, Act, Assert

Every good unit test has three steps. Arrange the objects and inputs. Act by calling the one thing under test. Assert that the result is what you expected. The same idea is called Given, When, Then in behaviour-driven development.

Our running example is a small price rule: orders of 5,000 or more get 10% off.

class DiscountCalculator {
    fun priceAfterDiscount(price: Int): Int {
        require(price >= 0) { "price must not be negative" }
        return if (price >= 5_000) price - price / 10 else price
    }
}

JUnit 4

JUnit 4 (current release 4.13.2) is the default on Android and the base for AndroidX Test.

// build.gradle.kts
dependencies {
    testImplementation("junit:junit:4.13.2")
}

// src/test/.../DiscountCalculatorTest.kt
class DiscountCalculatorTest {

    private lateinit var calculator: DiscountCalculator

    @Before
    fun setUp() {
        calculator = DiscountCalculator()          // Arrange (runs before every test)
    }

    @Test
    fun `no discount below the threshold`() {
        assertEquals(4_000, calculator.priceAfterDiscount(4_000))
    }

    @Test
    fun `10 percent off at 5000 or more`() {
        assertEquals(9_000, calculator.priceAfterDiscount(10_000))
    }

    @Test(expected = IllegalArgumentException::class)
    fun `negative price is rejected`() {
        calculator.priceAfterDiscount(-1)
    }
}

JUnit 5 (Jupiter)

JUnit 5 is a rewrite with a cleaner API and a more flexible extension model. Its pieces are Jupiter (the new API and engine), Vintage (runs old JUnit 3 and 4 tests on the new platform) and the Platform itself. Local tests can use it directly with one Gradle line.

// build.gradle.kts
android {
    testOptions {
        unitTests.all { it.useJUnitPlatform() }     // run local tests on JUnit 5
    }
}
dependencies {
    testImplementation("org.junit.jupiter:junit-jupiter:<version>")
    // Optional: keep old JUnit 4 tests running in the same module
    testRuntimeOnly("org.junit.vintage:junit-vintage-engine:<version>")
}

// src/test/.../DiscountCalculatorTest.kt
class DiscountCalculatorTest {

    private val calculator = DiscountCalculator()   // a new instance is created for every test

    @Test
    @DisplayName("10% off at 5,000 or more")
    fun tenPercentOff() {
        assertEquals(9_000, calculator.priceAfterDiscount(10_000))
    }

    @ParameterizedTest(name = "{0} becomes {1}")
    @CsvSource("0,0", "4999,4999", "5000,4500", "10000,9000")
    fun `discount table`(price: Int, expected: Int) {
        assertEquals(expected, calculator.priceAfterDiscount(price))
    }

    @Test
    fun `negative price is rejected`() {
        assertThrows<IllegalArgumentException> { calculator.priceAfterDiscount(-1) }
    }
}

The <version> placeholder stands for the latest release shown on the project’s page (each library is linked from the tables in section 5). Library versions change often, so take them from the source rather than from a blog post.

Assertions

JUnit ships with basic assertions: assertEquals, assertTrue, assertFalse, assertNull, assertNotNull, assertSame, assertArrayEquals and assertThrows. They are enough to start. Dedicated assertion libraries (next section) give you more readable failure messages and richer checks on lists, maps and objects.

5. The library map around JUnit

JUnit runs tests. Everything else (comparing values nicely, replacing collaborators, handling coroutines, simulating Android, driving the UI) comes from libraries around it. This is the map, grouped by job. Pick one from most groups; you do not need them all. Every library name below links to its official page, which is also where you will find the current version.

A. Test frameworks and runners

B. Assertion libraries

C. Mocking and test doubles

D. Coroutines, Flow and architecture components

E. Android on the JVM

F. Network, database and dependency injection

G. UI and instrumented testing

H. Screenshot (snapshot) testing

I. Coverage, property tests, BDD and contracts

J. Devices and clouds

6. Fakes, stubs and mocks

A unit test should check one class, so everything that class depends on (a database, a server, the clock) is replaced with a stand-in. The stand-ins are called test doubles, and there are five kinds.

Here is the same login test written both ways. The service under test is the interface UserRepository.

interface UserRepository {
    suspend fun login(email: String, password: String): Result<User>
}

// 1) A fake: a tiny real implementation. Reusable across many tests.
class FakeUserRepository : UserRepository {
    var failWith: Throwable? = null
    override suspend fun login(email: String, password: String): Result<User> =
        failWith?.let { Result.failure(it) } ?: Result.success(User(email))
}

// 2) A mock: a recorded stand-in, scripted per test.
val repo = mockk<UserRepository>()
coEvery { repo.login("a@b.com", "bad") } returns Result.failure(IllegalArgumentException())
// ... run the code ...
coVerify(exactly = 1) { repo.login("a@b.com", "bad") }

7. Testing coroutines, Flow and ViewModels

Most Android logic is asynchronous, and asynchronous tests are where beginners get stuck. The fix is to control time and threads. kotlinx-coroutines-test gives you runTest, which runs a coroutine on a virtual clock: a delay(5_000) completes instantly, and the test is deterministic.

Replace the Main dispatcher

A ViewModel launches work on Dispatchers.Main, which does not exist in a local test. Replace it with a test dispatcher using a rule you write once:

class MainDispatcherRule(
    private val dispatcher: TestDispatcher = UnconfinedTestDispatcher()
) : TestWatcher() {
    override fun starting(description: Description) = Dispatchers.setMain(dispatcher)
    override fun finished(description: Description) = Dispatchers.resetMain()
}

A ViewModel test

data class LoginState(
    val loading: Boolean = false,
    val loggedIn: Boolean = false,
    val error: String? = null
)

class LoginViewModel(private val repo: UserRepository) : ViewModel() {
    private val _state = MutableStateFlow(LoginState())
    val state: StateFlow<LoginState> = _state.asStateFlow()

    fun onLoginClicked(email: String, password: String) {
        viewModelScope.launch {
            _state.update { it.copy(loading = true, error = null) }
            repo.login(email, password)
                .onSuccess { _state.update { s -> s.copy(loading = false, loggedIn = true) } }
                .onFailure { _state.update { s -> s.copy(loading = false, error = "Wrong email or password") } }
        }
    }
}

class LoginViewModelTest {

    @get:Rule val mainRule = MainDispatcherRule()

    private val repo = FakeUserRepository()

    @Test
    fun `wrong password shows an error and stops loading`() = runTest {
        repo.failWith = IllegalArgumentException()
        val viewModel = LoginViewModel(repo)

        viewModel.onLoginClicked("a@b.com", "bad")

        val state = viewModel.state.value
        assertEquals("Wrong email or password", state.error)
        assertFalse(state.loading)
        assertFalse(state.loggedIn)
    }
}

Testing a Flow with Turbine

A Flow emits several values over time. Turbine collects them into a queue and lets you read them in order, with a timeout so a test cannot hang forever.

@Test
fun `emits loading, then the result, then completes`() = runTest {
    val flow = flow { emit("loading"); delay(100); emit("done") }

    flow.test {
        assertEquals("loading", awaitItem())
        assertEquals("done", awaitItem())
        awaitComplete()
    }
}

Pass the dispatcher into your classes (class Repo(private val io: CoroutineDispatcher)) rather than hard-coding Dispatchers.IO. A test can then supply its own and run everything on one thread.

8. Instrumentation tests: Espresso, Compose and UI Automator

An instrumentation test runs on a real device or emulator. Gradle builds your app and a second “test APK”, installs both, and starts AndroidJUnitRunner. The test process runs in the same process as your app, so it can reach into your code, start activities and read the live UI.

// build.gradle.kts
android {
    defaultConfig {
        testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
        testInstrumentationRunnerArguments["clearPackageData"] = "true"   // wipe app data between tests (with the orchestrator)
    }
    testOptions {
        animationsDisabled = true                          // no animations while testing
        execution = "ANDROIDX_TEST_ORCHESTRATOR"           // each test in a fresh process
    }
}
dependencies {
    androidTestImplementation("androidx.test.ext:junit:<version>")
    androidTestImplementation("androidx.test.espresso:espresso-core:<version>")
    androidTestImplementation("androidx.compose.ui:ui-test-junit4:<version>")
    debugImplementation("androidx.compose.ui:ui-test-manifest:<version>")
    androidTestUtil("androidx.test:orchestrator:<version>")
}

Espresso (Views)

Espresso’s trick is built-in synchronisation. Before each action it waits until the main thread is idle and background work it knows about (AsyncTask, its own idling resources) is finished. That is why Espresso tests are far more stable than tests that sleep. A test has three parts: find a view (onView(withId(...))), act on it (perform(click())), assert (check(matches(isDisplayed()))).

@RunWith(AndroidJUnit4::class)
class LoginScreenTest {

    @get:Rule val rule = ActivityScenarioRule(LoginActivity::class.java)

    @Test
    fun wrongPasswordShowsError() {
        onView(withId(R.id.email)).perform(typeText("a@b.com"), closeSoftKeyboard())
        onView(withId(R.id.password)).perform(typeText("bad"), closeSoftKeyboard())
        onView(withId(R.id.loginButton)).perform(click())

        onView(withText("Wrong email or password")).check(matches(isDisplayed()))
    }
}

• Lists: use RecyclerViewActions from espresso-contrib to scroll to or click an item.
• Intents: espresso-intents lets you check intended(hasComponent(...)) and stub the result of another app.
• Background work: register an IdlingResource so Espresso waits for your custom thread pool or network client.

Compose UI tests

Compose has no Views, so tests use the semantics tree: the description of the UI that accessibility services also read. You find nodes, perform actions and make assertions. Compose’s test framework synchronises with recomposition automatically.

class LoginScreenComposeTest {

    @get:Rule val rule = createAndroidComposeRule<MainActivity>()

    @Test
    fun wrongPasswordShowsError() {
        rule.onNodeWithTag("email").performTextInput("a@b.com")
        rule.onNodeWithTag("password").performTextInput("bad")
        rule.onNodeWithText("Log in").performClick()

        rule.onNodeWithText("Wrong email or password").assertIsDisplayed()
    }
}

To test one composable on its own, use createComposeRule() and call rule.setContent { LoginScreen(...) }. That is faster than launching the whole activity, and it can run on Robolectric as well. Add Modifier.testTag("email") to nodes that have no unique visible text. For waits that are not tied to recomposition, use rule.waitUntil { ... }.

UI Automator

Espresso and Compose tests can see only your app. UI Automator sees the whole screen, so it can press Home, open the notification shade, grant a system permission dialog, or switch between apps.

val device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation())
device.openNotification()
device.wait(Until.hasObject(By.text("Order shipped")), 5_000)
device.findObject(By.text("Order shipped")).click()

Choosing between them

These tools combine well: a Compose test for the screen, UI Automator for the permission dialog that appears on first launch.

9. UI automation and Appium

UI automation means a program drives the app’s user interface the way a person would: tap, type, scroll, read the screen. Espresso is UI automation from the inside. Appium is UI automation from the outside.

Appium is an open-source tool that exposes a standard web-automation protocol (the W3C WebDriver protocol, the same one Selenium uses) for mobile apps. You write a script in almost any language, Appium translates each command into a call to a platform driver, and the driver operates the device. It sees the app as a black box, with no access to your source code.

What makes Appium different

• Cross-platform. The UiAutomator2 driver covers Android and the XCUITest driver covers iOS, with the same client API. There are also Espresso, Flutter and other drivers, and Appium 2 installs drivers as plugins.
• Any language. Official clients exist for Java (usable from Kotlin), Python, JavaScript, Ruby and C#.
• Black-box. You test the installed APK, even a release build, the way a customer would. You cannot reach into the app’s internals.
• Real devices and clouds. Device farms like BrowserStack, Sauce Labs and AWS Device Farm speak Appium natively.
• Appium Inspector. A desktop app where you click an element on a live screen and see its locators.

Set it up

# You need Node.js, a JDK and the Android SDK (ANDROID_HOME set)
npm install -g appium
appium driver install uiautomator2
appium driver list --installed
appium                       # starts the server at http://127.0.0.1:4723

Write a test (Kotlin, JUnit and the Java client)

dependencies {
    testImplementation("io.appium:java-client:<version>")
    testImplementation("org.seleniumhq.selenium:selenium-java:<version>")
}

class LoginAppiumTest {

    private lateinit var driver: AndroidDriver

    @Before
    fun start() {
        val options = UiAutomator2Options()
            .setDeviceName("Android Emulator")
            .setApp("/path/to/app-debug.apk")
        driver = AndroidDriver(URI("http://127.0.0.1:4723").toURL(), options)
    }

    @Test
    fun wrongPasswordShowsError() {
        driver.findElement(AppiumBy.accessibilityId("email")).sendKeys("a@b.com")
        driver.findElement(AppiumBy.accessibilityId("password")).sendKeys("bad")
        driver.findElement(AppiumBy.accessibilityId("loginButton")).click()

        val error = WebDriverWait(driver, Duration.ofSeconds(5)).until(
            ExpectedConditions.visibilityOfElementLocated(AppiumBy.accessibilityId("error"))
        )
        assertEquals("Wrong email or password", error.text)
    }

    @After
    fun stop() = driver.quit()
}

Locators: how Appium finds an element

@OptIn(ExperimentalComposeUiApi::class)
@Composable
fun AppRoot() {
    Box(Modifier.semantics { testTagsAsResourceId = true }) {
        // your screens
    }
}

Appium or Espresso?

Neither replaces the other. A common split is Espresso or Compose tests for most UI checks, and a short Appium suite for the handful of flows the business cannot afford to break (sign-up, purchase, login).

Other UI automation tools

# login.yaml  (run with: maestro test login.yaml)
appId: com.example.app
---
- launchApp
- tapOn: "Email"
- inputText: "a@b.com"
- tapOn: "Password"
- inputText: "bad"
- tapOn: "Log in"
- assertVisible: "Wrong email or password"

10. Keeping UI tests reliable

A flaky test passes and fails on the same code. Flaky tests are poison: a red build that people rerun until it turns green teaches them to ignore red. Almost every flaky UI test comes from one of a few causes.

The robot pattern

If the test file knows every id and tag, one UI change breaks fifty tests. Put those details in a small helper class (a robot or page object) so tests read like the story and a UI change is fixed in one place.

class LoginRobot(private val rule: ComposeTestRule) {
    fun typeEmail(value: String) = apply { rule.onNodeWithTag("email").performTextInput(value) }
    fun typePassword(value: String) = apply { rule.onNodeWithTag("password").performTextInput(value) }
    fun tapLogin() = apply { rule.onNodeWithText("Log in").performClick() }
    fun assertError(message: String) = apply { rule.onNodeWithText(message).assertIsDisplayed() }
}

@Test
fun wrongPasswordShowsError() {
    LoginRobot(rule)
        .typeEmail("a@b.com")
        .typePassword("bad")
        .tapLogin()
        .assertError("Wrong email or password")
}

Run them in continuous integration

UI tests that no one runs are decoration. Run unit tests on every pull request, because they take seconds. Run a small UI suite on every pull request too if it stays under about ten minutes, and the full suite nightly or before release.

# .github/workflows/ui-tests.yml (excerpt)
- uses: reactivecircus/android-emulator-runner@v2
  with:
    api-level: 34
    arch: x86_64
    script: ./gradlew connectedDebugAndroidTest

The snippet uses the android-emulator-runner action. On Linux runners the emulator needs hardware acceleration (KVM) to be usable. Keep a rule for flaky tests: quarantine them quickly so they stop blocking others, fix them within a set time, and track how many reruns the pipeline performs. One automatic retry is a reasonable safety net. Three retries hide a real problem.

11. TDD: red, green, refactor

Test-driven development turns the usual order around. You write a failing test first, then write just enough code to make it pass, then clean up. You repeat this in very small steps, each a minute or two long.

Robert C. Martin (“Uncle Bob”) states it as three rules: do not write production code until you have a failing test; do not write more of a test than is enough to fail (a compile error counts); do not write more production code than is enough to pass the failing test.

A walk-through

We want the discount rule from section 4. We build it in three laps.

Lap 1, Red. Write the first test. It does not even compile, because DiscountCalculator does not exist yet. Create it with a body that fails.

@Test fun `10 percent off at 5000 or more`() {
    assertEquals(9_000, DiscountCalculator().priceAfterDiscount(10_000))
}

class DiscountCalculator {
    fun priceAfterDiscount(price: Int): Int = TODO()      // test is red
}

Lap 1, Green. Write the simplest code that passes. Not the final code, just the simplest.

fun priceAfterDiscount(price: Int): Int = price - price / 10      // green

Lap 2, Red. Add the next rule as a new test. Small orders must not get a discount.

@Test fun `no discount below the threshold`() {
    assertEquals(4_000, DiscountCalculator().priceAfterDiscount(4_000))   // red: returns 3,600
}

Lap 2, Green. The failing test forces the condition into existence.

fun priceAfterDiscount(price: Int): Int =
    if (price >= 5_000) price - price / 10 else price                    // green

Lap 3, Red and Green. Add a test for negative prices that expects IllegalArgumentException, then add require(price >= 0).

Refactor. With three green tests as a net, tidy the code: name the magic numbers and keep the tests passing.

class DiscountCalculator {
    private companion object {
        const val THRESHOLD = 5_000
        const val PERCENT_OFF = 10
    }

    fun priceAfterDiscount(price: Int): Int {
        require(price >= 0) { "price must not be negative" }
        return if (price >= THRESHOLD) price - price * PERCENT_OFF / 100 else price
    }
}

The benefits of TDD

The costs, honestly

• It is slower at first. Expect a dip in speed while the habit forms. An often-cited study of four industrial teams reported 40% to 90% fewer defects with 15% to 35% more initial effort. Other studies found smaller or mixed effects, so treat TDD as a good bet, not a guarantee.
• It has a learning curve. Writing a good first test needs you to understand the requirement and the design in advance.
• Bad tests give false confidence. A test suite that checks implementation details breaks on every refactor and slows you down.
• Over-mocking couples tests to code. If a test mirrors the production code line by line, it protects nothing.
• It suits some work more than other work. Logic with clear rules is a great fit. Exploratory work, quick prototypes and pixel-level UI are not.
• Tests need upkeep. They are code you now own.

Where TDD works best on Android

• Great fit: use cases, validators, mappers, reducers, ViewModels, repositories with fakes, parsers, anything with rules and edge cases.
• Good fit with care: network and database layers, using MockWebServer and in-memory Room.
• Poor fit: the visual design of a screen. Build it, then add a screenshot test or a short UI test after.
• Make it possible: keep the Android framework at the edges. Put logic in plain Kotlin classes behind interfaces and let Activities and Fragments stay thin (the “humble object” idea).

Cousins of TDD

12. A practical test strategy

Put each kind of check at the lowest layer that can catch it. A good first draft for a typical app looks like this:

Folder layout and naming

app/
  src/
    main/            production code
    test/            local tests (JVM)       <- most of your tests
    androidTest/     instrumented tests      <- fewer, slower
    debug/           test-only helpers such as the Compose test manifest

• Name the test class after what it tests: LoginViewModelTest.
• Name the test after the behaviour, not the method: wrong password shows an error, not testLogin2.
• Follow F.I.R.S.T: tests should be Fast, Independent, Repeatable, Self-validating and Timely.

What to do with coverage

Coverage tools (JaCoCo, Kover) tell you which lines your tests ran, not whether they checked anything. Use the report to find untested code, especially on risky branches. Do not set “90% or the build fails” as a goal for everyone, because people then write assertion-free tests to hit the number. A better pairing is a modest coverage floor plus occasional mutation testing with PIT, which proves your tests actually fail when the code is wrong.

Other kinds of test worth knowing

• Performance: Jetpack Macrobenchmark (startup, scrolling) and Microbenchmark (hot code).
• Accessibility: automated checks in Espresso and Compose, plus a manual TalkBack pass.
• Contract: Pact, so the app and its API agree on the shape of data.
• Exploratory and manual: a person looking for what nobody thought to automate. It is still valuable, just not as a regression plan.

13. Common mistakes

14. Takeaways, a starter path and glossary

• Shape the suite like a pyramid: many unit tests, some integration tests, few end-to-end tests.
• Keep logic in plain Kotlin so it runs as a fast local test. Reserve the device for what truly needs it.
• JUnit is the base. Add one assertion library, one mocking library and the coroutine helpers.
• Espresso and Compose tests drive your own app. UI Automator and Appium drive the device from outside.
• Fix flakiness at the cause: animations, timing, shared state and real networks.
• TDD improves design and gives a safety net, at the cost of early speed. Use it where rules are clear.

A four-step path to start

1. This week: write five JUnit tests for one plain Kotlin class, such as a validator or a mapper. Run them from Gradle.
2. Next: test one ViewModel with a fake repository, runTest and a main dispatcher rule.
3. Then: add one Compose or Espresso test for your app’s most important happy path, with a fake backend.
4. Finally: run the unit tests on every pull request in CI, and the UI test on a schedule. Once that is steady, add screenshot tests and a short Appium or Maestro flow if you need them.

Links and further reading

• Android Developers: Test your app
• Fundamentals of testing Android apps
• Local tests · Instrumented tests
• Espresso · Testing your Compose layout · UI Automator
• JUnit 5 user guide · JUnit 4 · android-junit5
• MockK · Mockito · Truth · Turbine · Kotest
• Robolectric · Paparazzi · Kover · JaCoCo
• Appium documentation · Maestro · Firebase Test Lab