android / android/codelab-android-paging
Request for test coverage
- Dominant language
- Kotlin
- Stars
- 509
- Forks
- 268
- PR merge metrics
- No merged PRs in 30d
Description
Hello,
Thanks for your work! Could you please add test coverage for common test scenarios?
I am moving from old paradigm (rxjava, model-view-presenter, etc) to a new one (data binding, view model, coroutines, etc) and looking for a right way to cover it with tests. In particular case I have screen with `PagingDataAdapter` and need to verify is there a call of `showError()` when API is set to return negative response from server.
In the past I would provide a `view interface` which will handle all operation on view layer within `activity|fragment` and mock it in the tests and call `verify(view).invoke(showError())`. Nowadays it looks like it is not a preferred way, `PagingDataAdapter` has `addLoadStateListener()` where, in theory, we also could provide mocks. I am working on this right now, but would like to see how Google team sees the right way to write tests for this and similar common cases.
p.s.
I have read [this your legal notice ](https://github.com/googlecodelabs/android-paging/blob/76cf68fa6cb5975d88f1283013598c0a5aa65819/CONTRIBUTING.md), as I haven't provided any code yet I leave this paperwork for later.
Contributor guide
Research direction
No file or test entry point is named. Start by reviewing the codelab's PagingDataAdapter usage and addLoadStateListener discussion, then determine how a negative API response should verify showError(). Done means adding coverage for this scenario and clarifying the recommended testing approach for similar cases.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- android, kotlin
- Domain
- mobile, testing
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100