Fix #2536: Add central testing utility for RecyclerView

[Sparsh1212]

Explanation

Fixes #2536:

1. Shift RecyclerViewMatcher to testing module and update the corresponding imports.
2. Add a central testing utility for RecyclerView

Checklist

• The PR title starts with "Fix #bugnum: ", followed by a short, clear summary of the changes. (If this PR fixes part of an issue, prefix the title with "Fix part of #bugnum: ...".)
• The PR explanation includes the words "Fixes #bugnum: ..." (or "Fixes part of #bugnum" if the PR only partially fixes an issue).
• The PR follows the style guide.
• The PR does not contain any unnecessary auto-generated code from Android Studio.
• The PR is made from a branch that's not called "develop".
• The PR is made from a branch that is up-to-date with "develop".
• The PR's branch is based on "develop" and not on any other branch.
• The PR is assigned to an appropriate reviewer in both the Assignees and the Reviewers sections.

[Sparsh1212]

@anandwana001 Changes done as per the discussion. PTAL.
The gradle build seems to be working fine, but the Bazel tests are failing, can you please guide me, where else should I make the corrections in the BUILD.bazel files if any.

[anandwana001]

Looks like as the file is no more in the app module, we need some update around BUILD files.

oppia-android/app/BUILD.bazel

Line 655 in 75c25b8

"src/sharedTest/java/org/oppia/android/app/recyclerview/RecyclerViewMatcher.kt",

[Sparsh1212]

@anandwana001 PTAL.

[anandwana001]

will review again, once the below-mentioned comments completed.

Also follow - https://github.com/oppia/oppia-android/wiki/Guidance-on-submitting-a-PR#clarification-regarding-assignees-and-reviewers-section

[anandwana001]

As we had shifted the RecyclerViewMatcher from app module to Testing module, we can remove the companion object and use it as we are using other functions in the testing module.

[Sparsh1212]

As we had shifted the RecyclerViewMatcher from app module to Testing module, we can remove the companion object and use it as we are using other functions in the testing module.

For doing this, I have to inject RecyclerViewMatcher in all the files, that were earlier using it as a companion object. Am I thinking right? Just wanted to confirm this, because this will involve changing approx 30-33 files.

[anandwana001]

As we had shifted the RecyclerViewMatcher from app module to Testing module, we can remove the companion object and use it as we are using other functions in the testing module.

For doing this, I have to inject RecyclerViewMatcher in all the files, that were earlier using it as a companion object. Am I thinking right? Just wanted to confirm this, because this will involve changing approx 30-33 files.

Yes

[Sparsh1212]

As we had shifted the RecyclerViewMatcher from app module to Testing module, we can remove the companion object and use it as we are using other functions in the testing module.

For doing this, I have to inject RecyclerViewMatcher in all the files, that were earlier using it as a companion object. Am I thinking right? Just wanted to confirm this, because this will involve changing approx 30-33 files.

Yes

Done

[anandwana001]

Our function verifyItemDisplayedOnRecyclerView is using atPositionOnView and there is also one function atPositionOnView.

Could you check what's the difference between them and when to use which function?

[Sparsh1212]

Our function verifyItemDisplayedOnRecyclerView is using atPositionOnView and there is also one function atPositionOnView.

Could you check what's the difference between them and when to use which function?

The purpose of atPositionOnView in the RecycleViewMatcher is to return a Matcher for a specific view within the item inside RecyclerView from a specified position.
The purpose of our function verifyItemDisplayedOnRecyclerView is that: by using this atPositionOnView, it first gets the matcher of that specific view and then verifies that it is displayed on the screen or not.
Hence, if we want just the Matcher, of a specific view inside RecyclerView then use atPositionOnView.
But, if we want to verify that a specific view inside the RecycleView is displayed or not, then one should use verifyItemDisplayedOnRecyclerView.

The two atPositionOnView (one that our function is using, and the one which is present in RecyclerViewMatcher are the same) Our function is just making use of that.

I hope that I got the question correctly, if you think that there is some misinterpretation here, then please let me know.

[anandwana001]

I Will take a look at this tomorrow, might look into some concise solution.

[anandwana001]

Thanks, @Sparsh1212
This is something cleaning up by shifting the RecyclerViewMatcher to the testing module.

Earlier I suggested, we can drop using companion object because I thought we might need context or testCoroutineDispatchers to inject in the class, but now as I looked more closely at it, I think we don't need any of them.
So, what I suggest here that we can use the companion object back. Sorry for this extra trouble, but I think this will going to be much cleaner.
Let me know your thoughts on this.

[anandwana001]

This is causing the failure. Please check my above comment. I think I missed something earlier and need revert.

[Sparsh1212]

Thanks, @Sparsh1212
This is something cleaning up by shifting the RecyclerViewMatcher to the testing module.

Earlier I suggested, we can drop using companion object because I thought we might need context or testCoroutineDispatchers to inject in the class, but now as I looked more closely at it, I think we don't need any of them.
So, what I suggest here that we can use the companion object back. Sorry for this extra trouble, but I think this will going to be much cleaner.
Let me know your thoughts on this.

No worries Sir, I will revert back the changes made for the companion object. But just for the sake of knowledge can you please let me know, why we won't be requiring context or testCoroutineDispatchers to inject in this class anytime in the future.

[anandwana001]

We cannot confirm whether we will be requiring this in future or not, but as it seems, currently there is no requirement of context or testCoroutineDispatchers in our utility class.