Automation scripts fail randomly due to visibility of elements - appium

I am using Robot with Appium for mobile automation
When we execute the individual scripts, things are passing, when we run it in bulk we get inconsistent result.
Most of the failures are cause of visibility of elements. Elements are displayed on screen still error say element is not displayed
Can someone help ?

Related

Debug Delphi Project Step by step

Is there is a way for debugging Delphi program in Rad studio with graphic output?
This means even graphic output(the command that has graphic output like print or shows a message and ...) run step by step.
For example inside loop command, we put print or add an item into list view and if we debug this part we can see the result in the form step by step? each turn of the loop show one print or adding to the list separately(by pressing F7 or F8 for debugging)
I hope I have asked my questions correctly.
Thanks
Is it possible to Debug Delphi applications in the way you describe? I'm afraid it is not.
Why not? Both application logic and UI rendering are done within the main thread. And when you set a breakpoint at certain line of code it stop the execution of the entire thread that the code is being executed from.
Since most if not all of your code is ran from main thread setting a breakpoint halts execution of the entire main thread of the application and thus prevents application windows to be redrawn.
In fact since redrawing of windows content is done during idle time of your application it means that running any long loop inside main thread means that the application UI will be updated only when the loop is finished.
You could theoretically force your application to update its UI on each loop cycle by calling Application.ProcessMessages before halting the code on a specific breakpoint.
But using ofApplication.ProcessMessages is not recommended as it could lead to scenarios where messages are not handled in expected order and thus could potentially cause you more problems elsewhere.
Also calling Application.ProcessMesages could seriously affect your application performance so if you decide to use it only use it for Debugging purposes.

How to take UI Automator dump for dynamic screens

We are trying to automate an android screen in which there is a progress bar which gets updated every second. Our framework retrieves the UI dump using adb shell uiautomator dump to get the UI heirarchy layout and then parses the xml to take further actions. We observed that for the above mentioned screen we are not able to get the dump and the above command reports an error "Could not get idle state".
On the same screen, we tried with appium and appium is able to retrieve the elements on UI. How is appium able to retrieve the information, which UI Automator is not able to retrieve.? We would not want to integrate appium as a tool at this point in our framework and would like to use ui automator dump itself. Is there a way to overcome this issue?
The thing is that Appium has 2 drivers for Android: AndroidDriver and UIAutomator2Driver (for Android 5+)
The 2nd one is a custom client-server implementation of UIAutomator:
https://github.com/appium/appium-uiautomator2-server
https://github.com/appium/appium-uiautomator2-driver
So it literally means "Appium don't use UIAutomator as is" any longer.
Google is no longer supporting UIAutomator (last release was july 2017) in favour of Espresso.
Check code of server part and you will understand that with UIAutomator2 Appium overrides lots of original UIAutomator stuff to solve issues like you described and many more.
If you don't want to use Appium, you still can reuse UIAutomator2 Server or at least write your custom framework on its basis and solve issues of original UiAutomator.

Tests on Bitrise (some consistently, some inconsistently) failing with "AX action" errors

I have a number of tests that I've written for an pretty substantial app (the app's been around for a few years longer than I have at this company) in the XCUITest framework. All of the tests pass consistently on my laptop and also the laptops of the other engineers.
When running tests on Bitrise, the first UI test fails every time on the setup phase with the following message:
testFixtureAttachment, UI Testing Failure - Failed to perform AX action for monitoring the animations of (app), error: Error -25204 performing AXAction 2043
Other tests usually pass but sometimes fail with errors such as:
UI Testing Failure - Failed to perform AX action for monitoring the event loop of (app), error: Error -25204 performing AXAction 2042
UI Testing Failure - Failed to scroll to visible (by AX action) TextField 0x7fe800f9fa20: traits: ... error: Error -25204 performing AXAction 2003
How can I resolve this so that, at a minimum, I don't have my first test always failing on setup?
Per feedback from the XCUITest team, this is happening because the simulator is CPU-starved and AX Action is timing out when spinning up the app. I was able to reproduce this on my own machine (which did not normally exhibit the failure) by using Power Management to step down my CPU.
Increasing the CPU allocation in Bitrise is the obvious solution. However, there is another, bizarre solution!
Immediately before the setup function for the tests, I have the following line:
let app = XCUIApplication()
This allows my various tests to call app. instead of the longer, full syntax.
Removing this line was found to prevent the error from occurring. This was found via this Apple Developer forum thread:
https://forums.developer.apple.com/thread/4472
So... hopefully that fixes this for other people, but it fixed it for me.
This is usually related to slower environments. Xcode is not really good to guarantee UI Test execution on older & slower machines. This is true for virtualized environments (like the one Bitrise.io uses), as well as for older machines or machines with HDD storage instead of SSD.
There are workarounds which might or might not help, depending on your project. You can find a list of related issues & possible solutions at: https://bitrise-io.github.io/devcenter/ios/known-xcode-issues/.
From the link, the solutions which work in most of the cases:
Try another Xcode version.
Try another Simulator device (e.g. instead of running the test in "iPhone 6" try it with "iPhone 6s Plus")
Some users had success with splitting the tests into multiple Schemes, and running those separately, with separate Test steps.
A great article about splitting tests into multiple Schemes: http://artsy.github.io/blog/2016/04/06/Testing-Schemes
Others reported that if you add a delay after app.launch() it can leave enough time for Xcode / the iOS Simulator to initialize the Accessibility labels, so that UI Tests can properly find the elements by the Accessibility labels.
Related StackOverflow & other forum links:
iOS 9 UI Testing - Test Fails Because Target Control Isn't Available (yet)
https://forums.developer.apple.com/thread/31312
https://github.com/fastlane/fastlane/issues/3874

Writing tests in Appium for ActionScript-based iPad app

I downloaded and set up Appium to run tests for an app developed in ActionScript for the iPad. I can run Appium just fine, however am having trouble actually writing tests. The problem is that I don't have any way to retrieve elements from the app. I thought I could do this with the selenium driver (I am currently creating an IOSDriver with Appium), however can't seem to figure out exactly how. All of the elements created by my application are flash-based (TextField for example), so I'm not sure how to retrieve them with the normal findElement method(s).
(Note I cannot update the code to comply with my tests, it must be the tests that comply with the pre-written code)
The Accessibility-based mechanism underlying the UI Automation feature represents every control in your app as a uniquely identifiable element. To perform an action on an element in your app, you explicitly identify that element in terms of the app’s element hierarchy.
This link is useful Tutorial
Tools You may like to try Although they are not exactly like UiAutomatorViewer which is for android
Reveal App
SparkInspector
Ios Hierarchy-Viewer
As far as Flas Elements concers Lets Look at this tutorial.

Xcode test navigator stuck on spinner using KIF tests

I am writing integration tests for my iOS app using KIF with the latest Xcode 5. When I run a test, a suite of tests, or all of them, the tests pass with no errors according to the console log, but the test navigator either takes many minutes to show the green pass icon for simple tests like Login, or keeps the spinner running indefinitely. I frequently have to Force Quit Xcode in order to clear the test results. I see this both on the simulator and the device.
I have tried using [tester waitForTimeInterval:3.0]; at the end of each test to no avail.
I have not found any discussions or solutions in all my searches, so I'm hoping to get some answers on this one.
Thanks in advance.
Thanks to Scott Anderson of Walmart Labs for this tip.
The cause of the slow test resolution was NSLog(). I have my own macro version that activates logs when compiled for Debug, which is the case for the Test builds. I log the output of all my server calls, which adds up especially during the registration process. When I disabled that, my tests came back green right after finishing, and no more hanging spinner.
The test navigator must be parsing the console output for XCTest result, slowly. This is my speculation, but would explain the slowness.

Resources