detroit-labs / katalon-mobile-util Goto Github PK

Hi,

After upgrading Katalon (from 6.3.3 to 7.0.8) and running a test that was previously working, I'm getting an error when I do ScrollListToElementWithText:

java.lang.NoSuchMethodError: com.kms.katalon.core.mobile.keyword.MobileBuiltInKeywords.delay(Ljava/lang/Object;)V
at com.detroitlabs.katalonmobileutil.touch.Scroll.scrollEntireList(Scroll.java:259)
at com.detroitlabs.katalonmobileutil.touch.Scroll.scrollListToElementWithXPath(Scroll.java:193)
at com.detroitlabs.katalonmobileutil.touch.Scroll.scrollListToElementWithText(Scroll.java:131)
at com.detroitlabs.katalonmobileutil.touch.Scroll.scrollListToElementWithText(Scroll.java:102)
at com.detroitlabs.katalonmobileutil.touch.Scroll$scrollListToElementWithText.call(Unknown Source)
at About Screen Links - Contact STM.run(About Screen Links - Contact STM:23)
at com.kms.katalon.core.main.ScriptEngine.run(ScriptEngine.java:194)
at com.kms.katalon.core.main.ScriptEngine.runScriptAsRawText(ScriptEngine.java:119)
at com.kms.katalon.core.main.TestCaseExecutor.runScript(TestCaseExecutor.java:337)
at com.kms.katalon.core.main.TestCaseExecutor.doExecute(TestCaseExecutor.java:328)
at com.kms.katalon.core.main.TestCaseExecutor.processExecutionPhase(TestCaseExecutor.java:307)
at com.kms.katalon.core.main.TestCaseExecutor.accessMainPhase(TestCaseExecutor.java:299)
at com.kms.katalon.core.main.TestCaseExecutor.execute(TestCaseExecutor.java:233)
at com.kms.katalon.core.main.TestCaseMain.runTestCase(TestCaseMain.java:114)
at com.kms.katalon.core.main.TestCaseMain.runTestCase(TestCaseMain.java:105)
at com.kms.katalon.core.main.TestCaseMain$runTestCase$0.call(Unknown Source)
at TempTestCase1573493983721.run(TempTestCase1573493983721.groovy:23)

We often want to test how different system settings (language, network, location) affect the app. Currently, the way to do this in Android seems to be to start the Settings app as a separate app during the test, make changes, then quit the settings app. This seems like something that would be a good candidate to automate.

https://forum.katalon.com/t/detect-system-language-setting-list-in-android-device/21186/2

At this point, I'm not clear if it would be something we could do on iOS.

For some reason, tapping buttons in WebViews doesn't seem to work reliably (at least in iOS). The buttons can be found, but tapping on them doesn't seem to work.

By tapping at a coordinate where the button is located, we should be able to work around this:

TestObject auth0_login_button = Finder.findButton('Auth0 Sign In Button')

// on retina displays, the pixel density is 2x (if might vary for other devices)
int screenScaleFactor = 2

// properties are stored as strings with decimals and can't be converted directly to integers
int x = Double.parseDouble(auth0_login_button.findPropertyValue('x')).toInteger() / screenScaleFactor
int y = Double.parseDouble(auth0_login_button.findPropertyValue('y')).toInteger() / screenScaleFactor
int height = Double.parseDouble(auth0_login_button.findPropertyValue('height')).toInteger() / screenScaleFactor
int width = Double.parseDouble(auth0_login_button.findPropertyValue('width')).toInteger() / screenScaleFactor

// tap in the middle of the button
// y value seems to be the BOTTOM of the element
MobileBuiltInKeywords.tapAtPosition(x + (width/2), y - (height/2))

Invoking:

Device.startApp([iosApp, androidApp], true)

with parameters "removeAppBeforeTest=true"

I receive a stacktrace exception that you can see here:

java.lang.NoSuchMethodError: io.appium.java_client.AppiumDriver.removeApp(Ljava/lang/String;)Z
    at com.detroitlabs.katalonmobileutil.device.Device.startApp(Device.java:77)
    at com.detroitlabs.katalonmobileutil.device.Device.startApp(Device.java:53)
    at com.detroitlabs.katalonmobileutil.device.Device$startApp.call(Unknown Source)
    at Utilities_7_Functionality_StartAppSwitcherDev.run(Utilities_7_Functionality_StartAppSwitcherDev:31)
    at com.kms.katalon.core.main.ScriptEngine.run(ScriptEngine.java:194)
    at com.kms.katalon.core.main.ScriptEngine.runScriptAsRawText(ScriptEngine.java:119)
    at com.kms.katalon.core.main.TestCaseExecutor.runScript(TestCaseExecutor.java:331)
    at com.kms.katalon.core.main.TestCaseExecutor.doExecute(TestCaseExecutor.java:322)
    at com.kms.katalon.core.main.TestCaseExecutor.processExecutionPhase(TestCaseExecutor.java:301)
    at com.kms.katalon.core.main.TestCaseExecutor.accessMainPhase(TestCaseExecutor.java:293)
    at com.kms.katalon.core.main.TestCaseExecutor.execute(TestCaseExecutor.java:227)
    at com.kms.katalon.core.main.TestSuiteExecutor.accessTestCaseMainPhase(TestSuiteExecutor.java:129)
    at com.kms.katalon.core.main.TestSuiteExecutor.accessTestSuiteMainPhase(TestSuiteExecutor.java:112)
    at com.kms.katalon.core.main.TestSuiteExecutor.execute(TestSuiteExecutor.java:81)
    at com.kms.katalon.core.main.TestCaseMain.startTestSuite(TestCaseMain.java:157)
    at com.kms.katalon.core.main.TestCaseMain$startTestSuite$0.call(Unknown Source)
    at TempTestSuite1562252659129.run(TempTestSuite1562252659129.groovy:35)

In order to close an iOS keyboard/submit a form field, we rely on the keyboard toolbar to exist and have a button labeled "Done" (or some variant). This won't always be the case, so we need a more robust way of closing the iOS keyboard.

We can use the following:

import com.kms.katalon.core.mobile.keyword.internal.MobileDriverFactory
import io.appium.java_client.ios.IOSDriver
import io.appium.java_client.remote.HideKeyboardStrategy

IOSDriver<?> driver = MobileDriverFactory.getDriver()
driver.hideKeyboard(HideKeyboardStrategy.PRESS_KEY, "Search")

Where we replace the text of the "Search" key with whatever the keyboard's "Enter" button is. NOTE: This could probably be an enum since iOS has a limited number of words you can use for the standard keyboard enter key.

Hi Cris,

I may be using it wrong, but still I'm informing on something I noticed regarding Scroll action.
I am not sure I understand the purpose of

I am sure it may make sense for most screens where text is more condensed.
In my test app scenario I use some blocks/containers of a dashboard on which you can tap.
The problem is that the scroll does not cover enough portion of the screen to make the yet invisible elements visible. So the searched container never gets into view and does not exist, from the tests point of view.
You can see more here:
https://www.youtube.com/watch?v=52sNgJgH3Qc
and here how the scroll-to elements are built: https://monosnap.com/file/84tTamL8D1XfhSEH3smplCVAVgV9pL

I tried both kind of scroll, by ID and text and by text only.
Not sure if the formula you use can be tweaked or parametrized further, so you can decide if you need the 50% screen scroll of 70% or 90%.

I also have a second app to test this with:

1. The view of the scroll: https://take.ms/vOHgT. Partially made by the library vs the total scroll that would be needed in order to click on the element.
2. The UI attributes: https://take.ms/gNme8
3. The code and result https://take.ms/zLHdX. When not using the id also the scroll seems total. When using the id also (the recommended way) the scroll seems only half way and the element is not actually found.

Please let me know if more information is needed to understand the scenario.

Thank you,
Cornel Neacsu

Katalon currently supports scrolling a list to an index for iOS, but not Android, because Android loads drop-down lists dynamically, so there's no way to know the indexing ahead of time:

https://docs.katalon.com/katalon-studio/docs/mobile-select-list-item-by-index.html

We should be able to do some counting of the currently displayed elements in the drop-down, then use Scroll.scrollEntireList() to get the next "page". Counting up the number of elements scrolled through total should give us the index.

See this issue on Katalon.

When Test Object isn't in the repository, it would be easier to troubleshoot if we knew that versus something just not on the screen.

Automated tests often require a login, which sends a one-time password (OTP) to the user via email or text message. Automatically reading those OTP seems to be a sticking point for a lot of testers.

We should be able to read the notifications and pull out the OTP per this thread: https://forum.katalon.com/t/capture-otp-while-sign-in-sign-up/18829

Appium doesn't have a way of returning the color of a UI element for native apps. A workaround is to take a screenshot of the app and find the color of a pixel. This could be an interesting feature to add to the utility.

https://discuss.appium.io/t/how-do-you-get-the-background-color-of-an-element-with-appium-webdriver/8384/9

Currently, Appium only supports openNotifications() and closeNotifications() to open/close the notifications pane. Once the pane is open, there isn't an easy way to interact with/validate the notifications. It would be nice to have a convenient way of searching for a notification and opening it.

To help new users with examples of how to use the library, a sample iOS test app and set of test cases would be useful.

The apps should contain the same functionality so that we can show how to reuse a test for both mobile platforms.

The apps should utilize the main features of the library:

• Test Object lookup
• Scrolling
• Text field entry

Hi,

Having a problem with findLabelAtIndex. I've created a new Label TestObject with type=XCUIElementTypeImage and name=detail-disclosure (as those are the type and name of the objects in the list I'm testing). When I run my test using findLabelAtIndex, the element isn't found and I see in the logs:

[35m[HTTP]�[39m �[90m{"using":"xpath","value":"(//[@type='XCUIElementTypeStaticText' and @name='detail-disclosure'])[6]"}�[39m
WARNING: Logger is not initialized. No log file will be written.
Would have logged:
Could not find any list elements matching xpath: (//[@type='XCUIElementTypeStaticText' and @name='detail-disclosure'])[6]

Not sure where XCUIElementTypeStaticText came from or why it's not using the type I set in the object: XCUIElementTypeImage.

Katalon Studio version: 6.2.2
Appium Version: 1.12.1

Thanks for any help/further info you can provide.

I'm getting this error while trying to do and import for com.detroitlabs.katalonmobileutil.testobject.Finder

Test Cases/Enquiries/Full Statement FAILED.
Reason:
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
file:/C:/Users/emaina/Katalon%20Studio/CBKL%20Customer%20App/Scripts/Enquiries/Full%20Statement/Script1551339769974.groovy: 20: unable to resolve class com.detroitlabs.katalonmobileutil.testobject.Finder
@ line 20, column 1.
import com.detroitlabs.katalonmobileutil.testobject.Finder
^

file:/C:/Users/emaina/Katalon%20Studio/CBKL%20Customer%20App/Scripts/Enquiries/Full%20Statement/Script1551339769974.groovy: 19: unable to resolve class com.detroitlabs.katalonmobileutil.testobject.TextField
@ line 19, column 1.
import com.detroitlabs.katalonmobileutil.testobject.TextField as TextField
^

2 errors

at com.kms.katalon.core.main.ScriptEngine.getScript(ScriptEngine.java:199)
at com.kms.katalon.core.main.ScriptEngine.run(ScriptEngine.java:194)
at com.kms.katalon.core.main.ScriptEngine.runScriptAsRawText(ScriptEngine.java:119)
at com.kms.katalon.core.main.TestCaseExecutor.runScript(TestCaseExecutor.java:331)
at com.kms.katalon.core.main.TestCaseExecutor.doExecute(TestCaseExecutor.java:322)
at com.kms.katalon.core.main.TestCaseExecutor.processExecutionPhase(TestCaseExecutor.java:301)
at com.kms.katalon.core.main.TestCaseExecutor.accessMainPhase(TestCaseExecutor.java:293)
at com.kms.katalon.core.main.TestCaseExecutor.execute(TestCaseExecutor.java:227)
at com.kms.katalon.core.main.TestSuiteExecutor.accessTestCaseMainPhase(TestSuiteExecutor.java:129)
at com.kms.katalon.core.main.TestSuiteExecutor.accessTestSuiteMainPhase(TestSuiteExecutor.java:112)
at com.kms.katalon.core.main.TestSuiteExecutor.execute(TestSuiteExecutor.java:81)
at com.kms.katalon.core.main.TestCaseMain.startTestSuite(TestCaseMain.java:157)
at com.kms.katalon.core.main.TestCaseMain$startTestSuite$0.call(Unknown Source)
at TempTestSuite1552574369619.run(TempTestSuite1552574369619.groovy:35)

When switching between apps in iOS, e.g. clicking a link in an app that opens a Safari window, there is a back button available at the top left of the screen which will take the user back to the original app. Currently, there is no way to identify that back button in Katalon's Spy Mobile as a Test Object. There is, however, a way to use Appium code to switch back to the original app:

HashMap<String, Object> args = new HashMap<>();
args.put("bundleId", 'com.myapp');
driver.executeScript('mobile: activateApp', args)

We could create a new function that combines handling the back button for iOS (using the above functionality) and Android's default back button handling.

Hi,

I tried running my tests using the ScrollListToElementWithText function on an Android 10 device, and while in the logs it indicates the scroll was performed, I don't see it happen when I watch. Then the test fails because the next element was not found, since the page wasn't scrolled.

I retried the same test on Android 9 and lower, and it's still working there.

In case it's relevant, I'm using
Katalon Studio: 7.2.1
Appium: 1.15.1

Hi Chris
firstly, fantastic addition for Mobile testing, this has saved me a lot of hassle.
I have an issue where value entered from 'typeText' does not always match expected result though.

This result is not consistent - I would say about 20% of the time today it has given wrong result (I did restart mobile phone by the way).

My element by xpath is '//android.view.ViewGroup[@content-desc="Have previous survey details been reviewed?"]/android.view.View'.

I use the following code (I cannot implement your object repository layout with this project):

TestObject havePrevSurveys = findTestObject('SummaryPage/txtHavePreviousSurveysBeenReviewed')

TextField.typeText(havePrevSurveys, reviewPreviousSurveys, 0).

The variable 'reviewPreviousSurveys' takes a value of 'Yes'. For this example the picker has values of blank, Yes and No. Sometimes it skips past Yes to next value. I have also tried a delay of 2 seconds before this step. The element is clearly on the screen.

Would appreciate any advice. In the meantime I will repeat the step with If statement if I see an odd result.
Regards
Dan

The default behavior when using Scroll.scrollListToElementWithText is that the list is scrolled downward. When hitting the end of the list there is no way to scroll back up. There are also instances when the list already starts at the bottom and we need to scroll to the top:

https://forum.katalon.com/t/scrolling-inside-a-menu/13453/18

We could add the ability to control the scrolling direction much like we can control the swiping direction.

Katalon's Mobile.swipe seems to alternate between relative and absolute coordinates. Let's create a Swipe class that is more robust and has some convenience features:

• Swipe using relative OR absolute coordinates
• Swipe, giving a direction and relying on the screen size to determine the coordinates (direction could be an enum)

There could be a "Done" button in the nav bar as well as the keyboard toolbar.

The current logic for closing the keyboard in iOS looks for buttons with text "OK", "SELECT", "Select", "DONE", or "Done". If we accidentally tap on the nav bar's "Done" button, it will close the entire screen, not just the keyboard.

We should add some more specific xpath to make sure we find the button on the keyboard toolbar.

Hi Cris,

Thank you for this BRILLIANT library, it is pure gold!
Can you please help producing a new JAR file that includes your latest Swipe&Scroll updates (2 days ago, for Katalon 6.2.0/Appium 1.12.1)?
You can see what I mean bellow:

Thank you,
Cornel

On iOS, the home button can be pressed using the following:

import io.appium.java_client.AppiumDriver as AppiumDriver
import com.kms.katalon.core.mobile.keyword.internal.MobileDriverFactory as MobileDriverFactory
import com.google.common.collect.ImmutableMap

AppiumDriver<?> driver = MobileDriverFactory.getDriver()
driver.executeScript('mobile: pressButton', ImmutableMap.of('name', 'home'));