Does Aws Device Farm supports Appium automation in ruby? - appium

I see AWS Device Farm support for Calabash to run Ruby tests, meanwhile, unable find any documentation regarding Appium Ruby combination for WebApp automation.

AWS Device Farm still provides only server-side way of executing tests, and its limited to Java/Python support in combination with Appium.
If you already have set of tests in Ruby, the best option is to look for device clouds with client-side execution (there are many of them today), then you won't be dependent in what language to code your tests, just set host/capabilities of cloud service.

Thanks for reaching out. We do not support appium/Ruby combination on the public fleet as of today. We do have plans to support more frameworks on the public fleet in 2018.
However, we recently launched a Feature called Direct Device Access where customer tests runs on the client side. You can use Direct Device Access to run your appium/ruby tests on Device Farm. However Direct Device Feature is only available on private devices.
To know more about Direct Device Access and Private Devices, please see the links below
http://docs.aws.amazon.com/devicefarm/latest/developerguide/direct-device-access.html
https://aws.amazon.com/device-farm/pricing/#privateDevices

You could get a private device pool in device farm. Then you could run any testing framework you want.
https://aws.amazon.com/about-aws/whats-new/2017/10/amazon-device-farm-launches-direct-device-access-for-private-devices/

Related

Is there a way to automate testing Apple Pay in Java using Appium?

I'm trying to automate testing Apple Pay on a food delivery app using Appium in Java and it seems that it can only be tested manually through sandbox tester. I tried searching for an automation solution but couldn't find any.
Appium uses the Apple XCUITest driver for UI test automation, but Apple restricts access to these controls even for its own tool. So this is not possible, unfortunately.

automate mobile device apps by direct communication to the phone via REST api

I'm currently working on a project that relies heavily on appium / selenium for automation. These frameworks are great for starting out, but the robustness isn't quite there, and requires a lot of extra hardware / software to run the automation. Such as macOS, xcode, adb, appium, selenium, usb connection or connected through WIFI ( what we currently have to use ). There is just a lot of dependencies in this automation stack, and it would be nice to have a cleaner, more reliable, and scalable solution.
So I'm wondering. Does any one know a way to run automation for iOS and Android via REST api using a server that lives directly on the device allowing us to communicate to the device like curl -POST <device_ip>:<port>/session/{sessionId}/openApp.
Think of the WebDriverAgent that Facebook built, but instead of being built with xcodebuild, that Agent just lives on the device. Essentially when you build this framework it starts up that server I'm describing, but its reliant on xcode, and i ultimately would like to remove xcode from having to be in the picture. I know that there are so many issues today I see with people having issues with both the WDA server and xcode. Specially with new versions, and how the WebDriverAgent is now archived by facebook.
Can't we just create an app that can act as the WebDriverServer running at all time, and will just use the same logic as today.. via start session, find elements by Id, click on them, and move on. This would also remove the need to running Appium on your computer, and rely on it to proxy your commands to that WDA server with iOS.
I know android is a much simpler picture, and I'm currently a little more focused on how to solve this with iOS at the moment.
I would appreciate any insight into this issue / question, and if anyone has suggestions on Appium, iOS automation, android automation, or other points that can be made please send me your feedback.
We do run our automation using real devices!
I have use Appium / Selenium to access from Rest API . In my opinion it is easier than building your own.
One of the solution was is we are currently working in a project using Flutter - that still need your Xcode to sign in the dependencies. You will also need to make sure libimobiledevice and ideviceinstaller are installed, and lastly modify Flutter. And we call the real device from rest api . We are currently scaling and monitoring the performance.
Another viable alternative which I can think of, doing it through XCTest will be easier than Appium . Just provide the end point in your app and create a wrapper in XCTest. Call the rest api and run the test in XCTest. It is more stable and faster in long run.
But for bulk of projects , I am still using Appium to test for iOS while we are evaluating this solution.
If you're open to using commercial tools, you can consider using xcuitrunner. It installs a recent version of Appium's fork of WebDriverAgent on your iOS device, launches it (and keeps it alive), and returns you a HTTP endpoint which you can use to interact directly with the WebDriverAgent.
It helps remove a couple of dependencies (such as Xcode), which may be difficult to manage. You'll still need a code signing certificate and provisiong profile from Apple, though.

What is the Recommended Approach to Automate IOS devices on Windows?

I've seen this topic going around and the answers on each site and post have given it a wide range when talking about how to automate IOS devices from Windows PC.
One side, I've seen it where mainly the answer is: it's not possible due to Apple's rules, or its really messy to set up and not worth the effort to maintain, (though not explained in detail why its messy.) On the other side, I've read articles and posts about recommendations of IOS simulators such as iPadian, Smartface, etc; along with articles suggesting to stay from this software recommendations stating that they likely contain malware and viruses.
I've found other sources suggesting Experitest, Appium Studio, Quamotion, TestProject to test and automate IOS on Windows PC. However, after reading the concerns of being cautious around these sites, and unable to proof if these studios/software legitimately support simulating real IOS environments on Windows and the arguments that are against going this approach, I can't tell which sources are reliable on this topic anymore.
The interest for me asking this question, as you can guess, is that I want to find a way to automate IOS on Windows and experience how run tests on iPhone.
I usually write my code in Eclipse Studio and use Oracle VM to create Android Emulators to test on. I'm fine if I need to have a physical IOS device in order to test.
All advice is appreciated.
Thank you
The best option I would suggest to automate iOS app on Windows is to use cloud based solution like BrowserStack, SauceLabs, etc.
This way you're sure that you will be using actual iOS device and the app would behave the same way as it would on real physical iOS device.
You can even inspect the app using Appium inspector and run the tests with ease as well.
The only drawback of using such solution is that most of them don't support latest version of Appium.
So the work around for this would be to setup Microsoft Azure DevOps pipeline on Mac OSX virtual machine and use latest Appium server version.
The tools you mention - Experitest, Appium Studio, Quamotion,... all use the same approach: they communicate with real, physical iOS devices over a USB connection and then launch an agent (WebDriverAgent or similar) on the device which you can use to automate iOS devices.
They will usually require you to at least configure an iOS developer certificate and provisioning profile (much like you would when you are testing on a Mac).
Most of them also offer you a free trial and support, so you can go ahead and install the software and give it a try.

Appium: How to create google account programmatically on aws device farm devices using java before starting test run for appium-testng

I want to run my automation android suite test cases on aws device farm.
Most of the script are created using gmail login.
On real time device gmail account can be configured manually ,so whenever scripts run already configured gmail account pop up for login
But in case of aws device farm ,gmail account are not configured on devices and its not possible as of now to configure gmail account on aws device farm before test run
So now I am looking for script which will run before my test run and it will configure gmail account programmatically on aws devices farm
Please make sure I am from testautomation background so please donot suggest answers in which android programming is required.My suite do not include any manifest file
Currently in my automation design I am using -> Maven(pom.xml), testng.xml (testng framework), java,POM model, eclipse IDE
There is no official support for this, you could try to use UIAutomator interface to login and logout with your google account, while different Android devices may have different UI elements...
This use case is officially supported by AWS Device Farm now. I have provided instructions and sample code for preinstalling your Google account and downloading apps from the app store (such as GMail) here: https://forums.aws.amazon.com/thread.jspa?messageID=997193&#997193
Let me know your thoughts,
Thanks,
Jon

Backdoor concept in Appium (like in Calabash) for UI testing

In Calabash you can implement a backdoor, i.e., a way to call a method in the app delegate during test case execution. This makes it possible to simulate non-UI/external events like a Bluetooth device to appear/disappear, etc. in simulator.
(I understand the backdoor concept is possible because Calabash-server is linked into the executable. Appium executes tests on the an untouched executable.)
Is a similar concept available in Appium? If not what are the alternatives then?
(I couldn't find anything in the Appium documentation.)
I have written a library in order to get a backdoor concept in my Appium setup. It is called Insider.
It includes the following features:
Send a message to the app from a remote script;
Send a message to the app from a remote script and wait for response;
Send local notifications through NSNotificationCenter with given parameters from a remote script;
Get device system state information (CPU, memory, IP address, etc) while running tests;
Manage files / directories in application sandbox (Documents, Library, tmp) while running tests;
GitHub: https://github.com/alexmx/Insider
API reference: http://alexmx.github.io/Insider/
We support this in a framework called Illuminator (full disclosure, I am the author), with an RPC channel called the automation bridge.
When instruments runs, we use the performTaskWithPathArgumentsTimeout function to call our script, which relays our supplied arguments to the running app (on simulator or on hardware). Any data returned from the app is relayed back to UIAutomation.
I just finished a project to do just this. In my case I needed to simulate some Bluetooth events. My apps are for Android and iOS, and they are written in C# using the Xamarin framework. The backdoor is accessed with Python or Robot Framework. But in the end it is just a MQTT server, so it would be possible to implement in other languages. I am sharing it here because others might find it useful:
https://github.com/sebnil/appium-mqtt-backdoor
It is not really a pure Appium solution, and more like a workaround. I found no robust way to implement a backdoor in Appium and make it work for both Android and iOS. But principally it works just the same when it comes to writing test cases in python or Robot Framework.
I had a very similar problem when developing iOS and Android apps in Xamarin, and testing them in Appium. Basically I found no robust way to implement a backdoor that would work the same in both Android and iOS.
You can do a backdoor into Android applications if you use the Espresso driver:
https://appiumpro.com/editions/51
I went with the solution of adding the backdoor into the test framework itself. So instead of implementing the backdoor in Appium, I implemented it in Python and Robot Framework (both of which can be used to control Appium). Basically the backdoor is implemented via a MQTT broker. More information here:
https://sebastiannilsson.com/blog/appium-mqtt-backdoor/

Resources