Robolectric

Visit Website

Introduction

Robolectric describes itself as the industry-standard unit testing framework for Android. Tests run in a simulated Android environment inside a JVM, without the overhead and flakiness of an emulator, and the README says Robolectric tests routinely run ten times faster than tests on cold-started emulators. The latest release, Robolectric 4.17, was published on 10 September 2026.

Robolectric supports running unit tests against 14 different Android versions, from Nougat (API level 24) to API level 37. You choose the SDK per test or class with the @Config annotation, which makes it practical to check behaviour across platform versions without maintaining a fleet of emulators.

Usage is simple: add org.robolectric:robolectric as a testImplementation dependency alongside JUnit 4 and AndroidX Test’s JUnit extension, then annotate tests with @RunWith(AndroidJUnit4.class). Because Robolectric supports the AndroidX Test APIs, many tests written with ActivityScenario, Espresso view matchers or Compose testing APIs can run either locally on the JVM with Robolectric or on a device as instrumentation tests. The README’s example builds an activity with Robolectric.buildActivity(...), moves it to the resumed state, clicks a button and checks a TextView.

Under the hood, Robolectric loads real Android framework code and replaces parts that need a device with “shadows”, Java classes that simulate platform behaviour. Developers can write custom shadows for platform classes when needed. The project’s architecture guide on robolectric.org explains this design.

Development is unusual: the GitHub repository is the source of truth for community contributions, while Google maintains an internal development tree synced to the google branch with Copybara and merged bidirectionally with master. Robolectric is also used in the Android platform itself through the external/robolectric project, where new SDK support often originates. This close relationship with Google helps Robolectric keep pace with new Android releases.

How it compares: Espresso and Compose UI tests on emulators or devices give the highest fidelity but are slower and need device infrastructure. Plain JVM unit tests with MockK or Mockito are fastest but cannot exercise Android framework classes. Robolectric sits between them, testing activities, fragments, views, resources and many system services quickly on the JVM. Screenshot tools such as Paparazzi and Roborazzi build on similar JVM rendering ideas, and Roborazzi runs on top of Robolectric.

In the quality loop, Robolectric lets Android teams run a large part of their UI and framework-dependent tests on every commit in CI without emulators, keeping device tests for the journeys that truly need real hardware.

The source code is at robolectric/robolectric on GitHub under the MIT licence, with about 6,100 stars; the most recent commit was on 11 November 2026.

Features

1. JVM-based Android tests: Run framework-dependent tests without an emulator or device.
2. Fast feedback: Routinely about 10x faster than cold-started emulators, per the README.
3. 14 Android versions: API 24 through API 37, selectable with @Config(sdk = ...).
4. AndroidX Test support: Write tests with shared APIs that also run on devices.
5. Shadows: Simulated platform behaviour, with custom shadows for special cases.
6. Activity and lifecycle control: buildActivity and ActivityScenario drive lifecycle states.
7. Resources and configuration: Test with real resources, qualifiers and configuration changes.
8. Gradle integration: Works with Android Studio, IntelliJ and standard Gradle test tasks.

Pros

1. No emulators in CI: Cheaper, faster and less flaky pipelines.
2. Backed by Google collaboration: Close alignment with new Android releases.
3. Free to use: Open source under the MIT licence, so the core tool costs nothing to use.
4. Actively maintained: The repository had commits as recent as 11 November 2026.
5. Community: About 6,100 GitHub stars.

Cons

1. Simulation, not a device: Some behaviour (hardware, OEM differences, rendering details) still needs device tests.
2. First run downloads: Android framework jars for each SDK are fetched on first use, which can slow cold CI runs.
3. Shadow gaps: Less common APIs may behave differently from real devices.
4. JUnit 4 runner: Tests use a JUnit 4 runner rather than native JUnit 5.

Usage and Links (Example)

Add the dependencies to your module’s build.gradle.kts (versions from the README) and enable Android resources for unit tests:

android {
    testOptions { unitTests.isIncludeAndroidResources = true }
}

dependencies {
    testImplementation("junit:junit:4.13.2")
    testImplementation("org.robolectric:robolectric:4.17")
    testImplementation("androidx.test.ext:junit:1.3.0")
}

A test in Kotlin, pinned to a specific SDK:

@RunWith(AndroidJUnit4::class)
@Config(sdk = [34])
class MainActivityTest {
    @Test
    fun clickingButtonChangesMessage() {
        Robolectric.buildActivity(MainActivity::class.java).use { controller ->
            controller.setup()
            val activity = controller.get()
            activity.findViewById<Button>(R.id.button).performClick()
            assertEquals("Robolectric Rocks!",
                activity.findViewById<TextView>(R.id.text).text.toString())
        }
    }
}

./gradlew testDebugUnitTest

Practical tips:

1. Cache Robolectric’s downloaded framework jars in CI.
2. Prefer AndroidX Test APIs so tests can also run on devices.
3. Keep a small set of device tests for hardware-specific behaviour.

Resources:

• Robolectric website
• GitHub repository
• Getting started

Pricing

Robolectric is free and open source under the MIT licence.

Recommended for?

1. Android teams wanting fast, emulator-free tests for activities, fragments and views.
2. CI owners reducing emulator cost and flakiness.
3. Library authors testing across many Android API levels.
4. Not a fit for hardware features or pixel-perfect device rendering.

Conclusion

Robolectric remains the standard way to test Android framework code quickly on the JVM, with broad API-level support and close collaboration with Google.

Use it for the bulk of your Android tests, and save devices for what only real hardware can verify.