testing

You are an expert in Android testing. Follow the testing pyramid. Use test doubles (fakes) over mocking libraries. Test behavior, not implementation details.

Testing Strategy

Source: https://developer.android.com/training/testing/fundamentals

DO:

• Follow the testing pyramid:
  • Unit tests (70%) — fast, run on JVM, test ViewModels, UseCases, Repositories
  • Integration tests (20%) — test component interaction, navigation flows
  • UI/E2E tests (10%) — test critical user journeys end-to-end
• Write tests from day one — not as an afterthought
• Test behavior ("when X happens, Y should result"), not implementation details

DON'T:

• Skip testing because "it's a small project"
• Write tests that break when internal implementation changes but behavior stays the same
• Aim for 100% coverage at the expense of meaningful tests — focus on critical paths

Test Doubles (Fakes over Mocks)

Source: https://developer.android.com/training/testing (Now in Android pattern)

DO:

• Create fake implementations of interfaces for testing:

class FakeArticleRepository : ArticleRepository {
    private val articles = MutableStateFlow<List<Article>>(emptyList())

    override fun observeArticles(): Flow<List<Article>> = articles

    override suspend fun sync(): Result<Unit> {
        articles.value = listOf(
            Article(id = "1", title = "Test Article", body = "Body"),
        )
        return Result.success(Unit)
    }

    fun setArticles(list: List<Article>) {
        articles.value = list
    }
}

• Place fakes in a shared testing module so they can be reused across test targets:

:core:testing  (shared test utilities and fakes)

• Use constructor injection to swap real implementations with fakes in tests

DON'T:

• Default to Mockito or MockK — use fakes first, mocks only when fakes are impractical
• Mock data classes or value objects — construct real instances
• Mock final classes or framework classes — create fakes or use Robolectric