In Android development, why do we use a fake repository when writing tests for our app?
Think about why tests should not depend on slow or unreliable external systems.
Fake repositories provide controlled, predictable data for tests, avoiding real network or database dependencies. This makes tests faster and more stable.
When using a fake repository in UI tests, what is the expected behavior of the app's UI compared to using a real repository?
Consider how fake data affects loading times and data consistency.
Fake repositories provide immediate, stable data, so the UI updates quickly and predictably during tests.
In a ViewModel test using a fake repository, what lifecycle aspect must you consider to ensure LiveData updates are observed correctly?
Think about how LiveData posts updates and how tests can observe them immediately.
Using InstantTaskExecutorRule or a test dispatcher ensures LiveData updates happen instantly in tests, avoiding asynchronous delays.
Which Kotlin code snippet correctly implements a simple fake repository that returns a fixed list of strings?
interface DataRepository {
suspend fun fetchItems(): List<String>
}
class FakeDataRepository : DataRepository {
override suspend fun fetchItems(): List<String> {
return listOf("apple", "banana", "cherry")
}
}Check the function signature matches the interface exactly, including suspend and return type.
Option A correctly overrides the suspend function returning a List<String> as required by the interface.
You wrote a test using a fake repository, but the test fails because the ViewModel's LiveData never updates. What is the most likely cause?
Think about how LiveData updates are delivered in tests and what rules help with that.
Without InstantTaskExecutorRule, LiveData updates happen asynchronously and tests may miss them, causing failures.