Test your Robolectric knowledge with a free interactive quiz — 20 questions with answers and explanations. No signup needed to play.
Question 1/12Score 0
What is the purpose of the `@Config` annotation in Robolectric, e.g. `@Config(sdk = [33])`?
In this round
What is the purpose of the `@Config` annotation in Robolectric, e.g. `@Config(sdk = [33])`?
What is a reasonable justification for a team incorporating Robolectric-based tests into their Continuous Integration (CI) pipeline, particularly given the speed characteristics discussed earlier?
What is a reasonable justification for a team specifically choosing to write a Robolectric test (rather than a pure, framework-free JVM unit test) for a piece of business logic that happens to only indirectly touch Android framework classes through a dependency, rather than directly?
What is a reasonable way a large, long-established Android codebase might gradually adopt Robolectric for an EXISTING suite of slow instrumented tests, rather than needing to rewrite the entire test suite at once?
What is a reasonable justification for Robolectric supporting testing against MULTIPLE simulated Android SDK versions specifically being valuable for an app that needs to support a WIDE RANGE of real-world Android OS versions across its actual user base?
What is a reasonable limitation or tradeoff of Robolectric's simulated Android environment, compared to actually testing on a real device or emulator running the genuine Android OS?
What is the purpose of the `@RunWith(RobolectricTestRunner::class)` annotation (or equivalent JUnit 5 extension) on an Android test class using Robolectric?
What is a reasonable justification for a team using Robolectric specifically to test how their app handles a `SharedPreferences`-based feature (Android's simple key-value local storage mechanism), rather than mocking out SharedPreferences entirely?
What is a reasonable way to think about Robolectric's overall value proposition as "bringing more of an Android app's testable surface into fast, standard unit testing" rather than requiring a strict binary choice between "pure JVM unit tests with zero Android dependency" and "slow instrumented tests for anything Android-related"?
What is a reasonable way Robolectric's ability to run WITHOUT an emulator specifically benefits a developer's LOCAL, day-to-day development workflow (as opposed to CI infrastructure specifically)?
What problem does Robolectric solve regarding the traditional distinction between Android "unit tests" (running on the JVM) and "instrumented tests" (requiring an actual device/emulator)?
What is a reasonable justification for the significant SPEED advantage Robolectric-based tests typically have over equivalent instrumented tests run on an actual emulator/device?