Is there any way to simulate touch events in ADL? If not, how do you properly debug an application that heavily relies on touch events?
Using a device seems to be the best way, though it also appears this overlaps a previous SO question that describes the same issue in the normal Android Emulator: Is there any way to test multi-touch on the Android Emulator?
Also with regard to code testing you can still write unit tests to test out your objects/methods and verify they have the appropriate input and output. If you're so inclined as to do so you could even have it dispatch events from UI components using code like
//in your code
Multitouch.inputMode=MultitouchInputMode.GESTURE;
someComponent.addEventListener(GestureEvent.GESTURE_TWO_FINGER_TAP, someHandler);
//and in your test
someComponent.dispatchEvent(new GestureEvent(GestureEvent.GESTURE_TWO_FINGER_TAP));
//verify appropriate change occured after a timeout or something of that nature
and should be able to get the appropriate reaction to the event.
more on gesture events here:
http://help.adobe.com/en_US/as3/dev/WS1ca064e08d7aa93023c59dfc1257b16a3d6-7ffd.html
more on multi-touch/gestures here as well:
http://www.adobe.com/devnet/flash/articles/multitouch_gestures.html
You can create multitouch app , run it on Your mobile and send Touch from device using WIFI .
This is how Im testing this .
But You can also write emulator that will read MouseEvents from stage and dispatch TouchEvents .
Related
I am working on automating an Android app. We have a screen that has a table wherein the cell values keep on changing in seconds. I have observed that it takes more than a minute for AndroidDriver to execute a single action.
I have read on some other forums about this and got to know that this is how the UiAutomator2 works and it has nothing to do with Appium. UiAutomator2 waits for elements to come to a static state and then performs the actions.
Since the dynamic elements on the screen are unavoidable, is there any workaround for this to make Appium scripts execute with good speed? Let me know what you all think of this. I will really appreciate your comments on this. Thanks.
Yes, that is right. It has nothing to do with Appium itself, but with UiAutomator. UiAutomator takes accessibility snapshots only when the application is in idle mode and the framework itself is not optimized for cases when there are constant changes in the page view. As a workaround, try to play around with waitForIdleTimeout such as setting it to zero or try with setting the disableWindowAnimation to true in the desired capabilities.
You could also try with running the following commands:
adb shell settings put global window_animation_scale 0
adb shell settings put global transition_animation_scale 0
adb shell settings put global animator_duration_scale 0
As a last resort, you could ask for the developers to provide you with a special build that has the animations removed in the source code.
I had the same issue, my specific problem was that the mobile app had a timer in the UI, that was changing its value every second.
Looks like the driver was waiting for the DOM to become idle, so it was SUPER slow because of that.
This simple command fixed the issue for me:
# Python code
driver.update_settings({"waitForIdleTimeout": 0})
Additional references:
https://appium.io/docs/en/commands/session/settings/update-settings/
https://github.com/appium/appium/issues/14155
Im just working with codeceptjs and using appium driver for testing android application.
Now i have different issues with this framework. Im currently working for a test, where i have to use swipeLeft, but it isnt working, there is nothing happen when that function is calling, also swipe, swipeRight, swipeUp, swipeDown. Has anyone already solved this problem or can i use alternatively a back() function or something?
Use the following syntax to make your code work:
I.executeScript('mobile: swipe', {direction: 'left'});
Have you consider Touch Perform (or Action) ? It is working for me
I have used webdriverio and it seems like Codeceptjs have similarities with their implementations of appium methods for mobile automation.
Are you testing using Android or iOS device?
Have you tried using different method overrides for Swipes?
On my experience, iOS and Android have different Speed and Offset settings you need to adjust the values until you get the swipe action working.
And of course you need to make sure you are selecting the appropriate View/Slider/Element that is scrollable, otherwise swipe will fail.
https://codecept.io/helpers/Appium
I'm trying to write a test that involves dragging and dropping (via SortableJS) to order some things on a table.
Here's basically what's in my test currently:
handle = find("[data-item-id='#{itemA.id}'] [data-js-sortable-handle]")
targetRow = find("[data-item-id='#{itemB.id}']")
handle.drag_to(targetRow)
This sort of works, except that rather than dragging to targetRow it drags to where my mouse actually is. So my test only passes if I put my mouse in the right location, and if I don't run them headless.
I'm unsure if this is more of a problem with Capybara, Selenium, or just because of the library I'm using.
Depending on exactly which type of drag and drop (JS emulated vs HTML5) the sortablejs library is using Capybara has to do different things. I don't really see how either of the methods it uses could drag to the wrong element (where the drop/mouse_up event occurs) but it's definitely possible the positions reported in the events may be off if your app depends on those positions. There are tests for both types of dragging in the Capybara test suite which do pass in headless and headed modes, so it definitely should work in at least basic cases. If you can provide a simple example that shows your issue, please file an issue at the Capybara project with the example and I'll take a look.
UPDATE: I took a look at the SortableJS code and found at least one reason why Capybaras HTML5 DND emulation isn't compatible with it. SortableJS handles the dragstart event by running some setup code via setTimeout. Since Capybaras code was all in one script the SortableJS dragstart setup code wouldn't get executed until after the drop event occurred which prevented elements from getting moved. I've made some changes to Capybara and released 3.23.0 which should play nicer with SortableJS.
I have a trivial react component that only shows a button:
<Button onPress={() => console.log("test")} title="Button"/>
When I put this button into a project I created with react-native init, it works as expected.
However, I have an existing project into which I integrated React Native (0.51.0) manually (because it doesn't use cocoa pods; I followed this guide: https://medium.com/#joshyhargreaves/adding-react-native-to-existing-ios-project-without-cocoapods-6f1ee9106009).
The project seems to work fine: the UI loads, the button gives visual feedback when I tap it. But the buttons onPress event is not fired, so it does not log anything.
There are no errors or warnings (except Class RCTCxxModule was not exported, but it seems to be safe to ignore this).
I'm now out of ideas of what I could try or how I could debug this issue short of diving into Reacts touch handling code. Here's what I tried:
Made sure to only have one RCTRootView, and that it is created in the main thread.
Checked for any suspicious things happening in the remote debugger; everything looks normal (no exceptions thrown or warnings logged).
Tested a few other components that should fire events; for example, TouchableOpacity does not work either.
Logging something after a timeout does work, so it doesn't seem like anything is deallocated prematurely
Checking for errors reported by the metro bundler: it doesn't print anything
Any ideas on what I need to do to get my button to print "test" when I tap it?
I think you have not Debug JS Remotely option enabled. If you don't you have to open React Native Debug Menu Pressing (command / control) + D or shake your device if you are debugging with real device. Then just press Debug JS Remotely and it should appear in the Google Chrome. Then inspect and open the console. There it is!
This mite caused by date diff between the host (your computer) and the client (the mobile device)
You can check this by running adb shell "date" && date
to see if there is a diff.
If there is one go to your mobile device and toggle automatic date & time off and back on.
Then test time diff again as mentioned, if there is no more diff, tap events should work in debug mode
More details in the original git issue answer by - Alex Ciarlillo
We are trying to migrate from UIAutomation to XCUITests and did use the captureScreenWithName() API to programmatically generate screen shots.
What is the replacement in the XCUITests ?
(I know that automatically screenshots are taken in case of error, but we have a special test which runs forever in a loop and evaluates QA click,tap commands via network similar to the appium-xcuitest-driver https://github.com/appium/appium-xcuitest-driver)
Do I need to rip out private headers (XCAXClient_iOS.h) like the appium guys did in order to get a screenshot API?
Edit
I used the actual code line for the accepted solution from
https://github.com/fastlane/fastlane/blob/master/snapshot/lib/assets/SnapshotHelper.swift and its just this for IOS
XCUIDevice.sharedDevice().orientation = .Unknown
or in objC
[XCUIDevice sharedDevice].orientation =UIInterfaceOrientationUnknown;
I use a process on the host to lookup in the "Logs/Test/Attachments" directory all Screenshot_*.png files before the call , and find the new shot then after the call as the new file added in this directory.
Gestures (taps, swipes, scrolls...) cause screenshots, and screenshots are also often taken while locating elements or during assessing expectations.
Fastlane's snapshot tool uses a rotation to an unknown orientation to trigger a screenshot event (which has no effect on the app): https://github.com/fastlane/fastlane/tree/master/snapshot - you can use this if you want to be in control of some screenshots.