Hi All, we are trying to automate native app on both iOS and Android platform. we wanted to run our test cases on both the platform but the xpaths and locator values for same objects are different in both the platform. is there any way to manage these type of objects ? or we have to create duplicate object files each for android and iOS? Thanks in advance @Katalon_team @kazurayam
+1 if inevitable
1 Like
I would rather change the target app so that a target element can be pointed by the same locator on both of ios and android.
Why not you put id attribute or data-id attribute with unique values to all the elements to test? Provided with unique identifications on the target element, common to both ios and android, you can locate the elements by a definitive locator.
You should change the target application test-friendly if possible. That would make your life much easier.
1 Like
Thanks @kazurayam for quick reply as always. setup of these ID Attributes with unique value across both platform will be done by developer team right ?
That’s correct. Any sane application should be developed with this in mind.
Corner cases may occur, e.g the id is dynamically generated.
This make it unique, but unpredictable.
If that is the case you have to carefully study the DOM of your AUT (or what is the equivalent for android/ios apps, I am not familiar with this)
The locators generated by the recorder/inspector are just ‘best guess’ but most of the time are not quite ‘best’.
Anyway, you have to reach out to your development team for now.
1 Like
It is common to have different xpaths and locator values for the same objects on different platforms, as the underlying implementation of the app can be different on different platforms. In such cases, you can use a platform-specific object repository for each platform, and store the xpaths and locator values for the objects specific to that platform.
For example, you can create a separate object repository file for Android and another for iOS, and store the xpaths and locator values for the objects in each file accordingly. Then, you can use the appropriate object repository file for the platform on which you are running the test cases.
Alternatively, you can also use a single object repository file and use conditional statements in your test scripts to use the appropriate xpaths and locator values based on the platform on which the test is running. This can help you avoid duplicating the object repository files.
I hope this helps. Let me know if you have any further questions or need more assistance.
Yes. You should communicate with the developer team closely to find a way how to make the works of both teams enjoyable.
1 Like
Hi @waqas Thanks for elaborating it nicely. I was also thinking on having conditional statements but how we will implement that in a katalon framework where we store objects in a page wise folder ? assume that I have one object with name “TestObject” with ID on Android as “testid:LogIN” and on iOS it is SignIN . How can i write conditional statements on it.
You can not write any conditional statements on a Test Object.
I believe @waquas suggested to create some Groovy code (either of Test Case or custom Keyword) with
if (i am on ios) {
use a Test Object made for ios
} else if (i am on android) {
use a Test Object made for android
}
ok. so help me in understanding this … with these approach that you posted we would still need 2 objects 1 for android and 1 for iOS. and with this method i can call it depending on the platform. so no need to write 2 separate scripts . the objects will get called depending on the platform chosen in one single script…is this correct understanding ?
Yes, exactly.
I think you would want to create a custom Groovy class in the Keywords folder as described in
For example you want to create a Groovy class Keywords/com.sumiranrau96/TestObjectChooser.groovy like
package com.sumiranrau96
import com.kms.katalon.core.testobject.TestObject
class TestObjectChooser {
static TestObject choose(String testObjectName) {
TestObject found
if (i am on ios) {
found = findTestObject("ios/" + testObjectName)
if (found == null) throw new IllegalArgumentException("ios/" + testObjectName + " is not defined. You , silly body.")
return found
} else if (i am on android) {
found = findTestObject("android/" + testObjectName)
if (found == null) throw new IllegalArgumentException("android/" + testObjectName + " is not defined. You , silly body.")
return found
} else {
throw new IllegalStateException("i dont know where i am")
}
}
Your test case could be something like
import com.sumiranraou96.TestObjectChooser
TestObject tObj = TestObjectChooser.choose("myGreatestTestObject")
...
1 Like
It is likely that you find in some cases a single Test Object is applicable to both ios and android. In that case you would want to create a folder Test Object/shared where you save the sharable Test Objects.
In that case your TestObjectChooser class could be:
static TestObject choose(String testObjectName) {
TestObject found = findTestObject("shared/" + testObjectName)
if (found != null) {
return found
} else {
// do the same as before
if (i am on ios) { ... }
else if (i am on android) { .... }
}
}
It would be desirable if you could locate as many Test Objects under the shared folder somehow (assign ID, etc) rather than creating pair of Test Objects for ios & android.
This is the dark path of xpath.
This is why we suggested, if possible, the AUT should have a certain unique id (or whatever other attribute, it can be a certain ‘testing_id’ ) to help the life on the QA engineers.
It is known that developers tend to look only on what they intend to achieve.
(and usually they are paid more because they are considered being more important)
But as far as I know, those days we work with Agile philosophy in mind.
This implies a strong communication between the testing teams and the development teams.
If one piece breaks into the chain, everything breaks!
Cheers,
bionel!
1 Like
+1 to this
Feedback from the testing team to the development team is valuable, I believe.
Application should be developed to be test-friendly. Test-friendly application can be high-quaility software. Otherwise, it will melt-down.
2 Likes