Closed cee-dee closed 1 year ago
Hi, @cee-dee! firstChild method returns literally the first child in the list. The child type you provide to this method serves only for casting item to exact type you expect. It's not used as a matcher. Method isFirst is a check that serves as an assertion. Again, it's not used as a matcher. I suggest you to use childWith method. It would look someting like this:
onScreen<AutoCompleterScreen> {
resultList {
childWith<AutoCompleterScreen.AutoCompleterResult> { withDescendant { withId(R.id.destination_title) } } perform {
// your check here
}
}
}
Please, check kakao samples if you need more info
Thank you for the suggestion! I've tried this and it gives me
androidx.test.espresso.AmbiguousViewMatcherException: 'view holder: ((view is an instance of android.view.ViewGroup and has descendant matching (view.getId() is <2131428706/de.android.homes.alpha:id/destination_title>)))of recycler view: (view.getId() is <2131428702/de.android.homes.alpha:id/destinationList>)' matches 5 views in the hierarchy:
...
Actually, I need to match the first of these views on tap on it, like I implemented the Espresso matcher doing that. That was the reason why I tried also using first
. Is there a way to achieve this combination?
I found the solution. So, it's possible using Kaspresso/Kakao ootb without usingEspresso code.
Actually, the code
onScreen<AutoCompleterScreen> {
resultList {
childWith<AutoCompleterScreen.AutoCompleterResult> {
withId(R.id.auto_completer_item_root)
isFirst()
} perform {
click()
}
}
}
had two flaws:
a) auto_completer_item_root
seems to not be part of the RecyclerView item, I need to exchange it against destination_title
. In the end, I could even remove the withId
check since the Kakao did that check using childWith
.
b) In my scenario, the RecyclerView was pre-populated with data from a previous search, meaning that already items matching the above criteria were in the RecyclerView, but clicking on them wasn't intended until the RecyclerView is updated with the currently running search (which is issued earlier in the test). Thus I needed to add a check that ensures the search results are for the current keyword.
This is the working code:
onScreen<AutoCompleterScreen> {
resultList {
childWith<AutoCompleterScreen.AutoCompleterResult> {
containsText("current keyword")
isFirst()
} perform {
click()
}
}
}
@cee-dee do you know, that your childWith
works wrong? :) For example, I have this recyclerView:
and this check:
recyclerView {
childWith<ChatMainScreen.ChatRecyclerItem> {
containsText("Добро пожаловать в наш чат")
isFirst()
}
}
And test is passed! But it's not the first, it's index is "3" in the list! Also we can check it, for example, for visibility, and it will be visible and invisible in the same time :)
No, it doesn't work wrong. That is exactly the behaviour I intended: first item in the Recycler view that contains the text.
For my tests it's not true. I described it above
If you need to check for something different, then write other matching for that. Obviously if you have differing requirements you then cannot use my matching.
Am 27. Sept. 2023, 11:46, um 11:46, Pirokar @.***> schrieb:
For my tests it's not true. I described it above
-- Reply to this email directly or view it on GitHub: https://github.com/KasperskyLab/Kaspresso/issues/547#issuecomment-1737068110 You are receiving this because you were mentioned.
Message ID: @.***>
I'm having issues operating a RecyclerView with different ViewTypes in my UI tests, although I'm using the latest Kaspresso 1.5.2:
The RecyclerView is used for an Auto Completer and has two ViewTypes:
What I want to achieve: click on the first item in the RecyclerView which has a View matching my "regular" items. Caveat: the first item in the RecyclerView does not have this type but the above mentioned "special item" type.
The view xmls look like:
and
I've got a screen object for the RecyclerView:
I tried different approaches in my test, I was hoping that this will work:
But it wasn't.
I kept on experimenting and this one worked once, but I couldn't repeat it, so it might be related to the app not being freshly installed:
On the other hand, I managed to come up with some Espresso code that actually works -- but as I'm using Kaspresso, I'd like to learn how to leverage that framework:
using
Maybe, Kakao/Kaspresso has problems with the looping of the MainThread, but it should support going without that because of its internal flakysafe implementations.