I have some limitations/observations made after a couple of weeks of Mobile application testing and recent upgrade to Appium 1.12.1 and Katalon 6.2.0, on Windows 8:
Appium allows object identification by partial id/class/general attribute Monosnap.
Katalon (although by UI it seems it allows this, the same as for Web testing) does not identify objects by partial (contains, ends with, starts with) attribute values. Multiple trials made for object identification Monosnap + actual try to find elements and failure Monosnap
This would be GREAT! to have it functional since it is already supported in Appium and it helps covering multiple instances of the same application (flavors).
Since upgrading to Appium 1.12.1 the object spy is no longer collecting the “instance” attribute of the object. This is very useful for Lists/RecyclerViews, may be something that depends on Appium. Monosnap
- By the way, together with the mobile dev team I am struggling to find a best practice approach on mobile object design&selection for list/repeaters/RecyclerView of elements for lowest flakiness possible.
I rely on this Appium Pro: How to Pick the Right Locator Strategy + Appium Pro: Making Your Appium Tests Fast and Reliable, Part 2: Finding Elements and on bellow answer:
but still not sure what is best practice regarding lists of repeated elements.
Can anyone point in a good direction, particular example?
I cannot help to feel that Mobile is so less equipped in this “battle” compared with Web .
@Chris_Trevarthen can you confirm if my observations are correct?
You are the expert in the mobile field here
@devalex88 or @Zarashima, help please.
If I am correct, this is quite a big obstacle to obtaining stable mobile testing.
@Katalon_team: please help with any kind of feedback.
@duyluong, @ThanhTo please confirm at least if the issue is valid and if it can be taken into consideration in next sprints.
Transparency is all a community needs.
Just want to let you know that the development team is made aware of your inquiry. Due to the complex nature of the problem I cannot confirm wether it would be included in the next sprint or not because our back log is quiet packed.
For lists of the same elements on a screen, I use the same
resource-id (for Android) or
name (for iOS). This can make it easier to manage dynamically generated lists of repeated elements. Accessing a particular element from a list does mean you have to either get it by its index or loop through the elements in the list until you find a matching one.
For katalon-mobile-util, I’ve created a couple of convenience functions that work on static text labels that have the same ids. Both functions assume that you’ll create a generic label Test Object as the base, given a
name (but no
You can get one of the elements by its index: https://github.com/detroit-labs/katalon-mobile-util#finding-a-label-from-a-list-by-index
int index = 3 // first element in the list is at index 1, so this gets the 3rd element
TestObject labelAtIndex = Finder.findLabelAtIndex('Generic label element', index)
Or you can get one of the elements by its text: https://github.com/detroit-labs/katalon-mobile-util#finding-a-label-from-a-list-by-the-label-text
TestObject labelWithText = Finder.findLabelWithText('Generic label element', 'Label Text')
Hope this helps,
Thank you @Chris_Trevarthen for the detailed feedback.
I agree with your approach, and this is the conclusion I produced for myself also during the last weeks. Only I needed a confirmation by someone else also.
However I feel that it still is not as stable as the Web object recognition is. I may only be nostalgic for the way the Web UI object identification works. I am aware that the Mobile UI/Appium does not work that way and this is the best we can get at the moment.
But I am still uneasy to:
- search an element by plain text rather by ids - because of multilanguage applications. Only option here is producing a dictionary of texts to search for each language?
- use instances - you yourself (hope I am not wrong) advise not to use index too much, unless no other way. And I also agree. What is today the third element tomorrow can be the fourth. It seems that it is possible to have specific ids inside a RecyclerView in Android as our mobile dev team has experimented. It does not seem easy but also does not seem hard to do. If this confirms I would very much use this approach also (resource-id=“com.example.testexample:id/second”, resource-id=“com.example.testexample:id/third”, etc). Does anyone know if this is a valid observation or just a wrong conclusion?
- test flavour apps - (versions of the same app for different clients) testing does not seem to be possible as Katalon is today. These app versions have a different package name and Katalon does seem to send to Appium only the full id, including the package name.
I feel that it can and it should be even better than this, so the tests are not too flaky on the long run.
And your library is pure gold for mobile testing, it improves so many aspects. I feel it should be included in Katalon by default, or made a plugin.
Please help with a feedback on the #1 observation in the initial post (3rd in this comment). Can you validate my observations or am I wrong?
Unless Katalon can send to Appium part of the ID, without including the package name, no flavor testing can be done in Katalon. Only in native Appium.
And that means that we either continue testing and come back later to change all captured objects or our mobile testing is suspended until this issue is improved. I love the Object Repository of Katalon and would rather continue using it than continue with native Appium xpath/id coding.
There is a good workaround for this flavor testing blockage.
By @Chris_Trevarthen’s appreciated feedback, using parmeterized tests helps a lot.
Which of course I have used before in Web testing but did not considered here at all .
I have made a test and it definitely unblocks multiple flavor app development.
With global variables per profile and helper functions, I am now able to cover multiple package/apps selection by id of objects in Katalon.
Please see workaround bellow:
image.png1178x603 26.5 KB
So this is now not such a big blocker anymore.
However it would still be great to have Katalon natively selecting partial object attributes (contains, ends with) similar to Web apps. It would bring the multiple Web app select possibilities in the Mobile app world.
Since Appium already supports this natively and also the Katalon UI is ready for it by parameter options: equal, contains, starts with etc.
Plus, the above workaround makes difficult navigating from the Katalon UI editor to the actual TestObjects that you work with.
image.png1012x881 63.9 KB
So, not urgent anymore, but nice to have from @Katalon_team.