I'm using Calabash framework for test automation and there's a need to automate the sign up scenario of an Android/IOS application.
Just so happens that is that one of the sign up steps is to link to a Paypal account.
At least for Android, I can confirm that the Paypal/Braintree SDK opens the default external browser for the user to complete the linking process, when this happens Calabash framework cannot interact with the browser and the test hangs.
Can I force Paypal SDK to use an embedded webview for the linking process?
If not, does anyone picture another way of automating this scenario?
Although this is a common scenario (i.e. facebook sign in, Google sign in etc...) unfortunately neither calabash framework currently provide a documented way to interact with 3rd party applications. The limitation lies in security features of both operating systems which disallow automation to jump outside of its process (and mobile browsers are separate processes).
However, as I mentioned this is a common scenario so there is a solution: we generally advise people to use something called "backdoor methods", which are methods inside of your application that you can trigger directly from calabash. Documentation is available for iOS and Android from Xamarin's official docs pages.
The idea is that you'd create a backdoor method in your application that simulates the user having successfully logged in/done whatever via Paypal/facebook/whatever. When you get to the part in your test where the user would normally go to that third party app, you instead invoke the backdoor.
Consider also philosophically: what happens if Paypal/facebook/whatever is down? What if the user isn't able to log in due to factors outside of your application's control? It doesn't make sense for your app's test to fail in this case, because the failure is unrelated to your application. In other words, backdoors allow you to test your app, not Paypal.
Hope this is helpful, please let me know if you'd like more info.
Related
AWS has a 'remote-desktopy' feature (https://aws.amazon.com/blogs/aws/aws-device-farm-update-remote-access-to-devices-for-interactive-testing/) as part of its device farm, but it is far too slow to use in browser. Does anyone know if there is a programmatic/CLI way to interact with that system?
I would like to test the functionality of a third party app on a cloud based mobile testing platform such as Firebase Test Lab, or AWS device farm. I have no way to instrument this app.
The testing requires I download two apps on the device (one is the app to be tested, the second has a supporting function). At the start of the test I have to launch the support app, and then switch over to the app I am testing. I imagine the only way to do this is via the device's 'home' button. The actual testing is just a set of basic UI interactions.
Does the Firebase Test lab or other platform have a feature that I could use to do this?
If there was a way to extract events from the AWS remote-desktop, I could see an approach using a selenium/other webdriver. But I am not sure this a real option.
Any thoughts on this are appreciated.
Thanks!
"The UI Automator APIs allow you to write robust tests without needing to know about the implementation details of the app that you are targeting. You can use these APIs to capture and manipulate UI components across multiple apps" (documentation)
To tap the Home button you can use UiDevice.pressHome().
The Android Instant Apps is a new thing, and I just wanted to know if it can be integrated with the Hybrid app structure (HTML/JS with Cordova wrapper).
I'm not a native app developer so I'm not sure of this myself.
According to Googlers ,well main idea behind instant app is
To make the native app experience as convenient as surfing to a web
site. “Web pages are ephemeral,They appear, you use them, and never
think about them again.” Apps, have lots of friction and
often you only want an app to perform one action or to get a specific
piece of information.
Google's examples of Instant Apps included museum or resort apps with maps and schedules, along with apps that help you pay for parking. These are the kinds of rarely-used apps that are useful in the moment, though you wouldn't necessarily want to install them on your phone beforehand or keep them around afterward. Developers can, however, can provide "call to action" links that encourage users to download and install apps that they find particularly useful.
Instant Apps are a logical evolution of App Links, a Marshmallow-era feature that lets installed apps designate themselves as the default options for opening certain kinds of links. For instance, clicking a link to Pinterest might open up the Pinterest app rather than Pinterest's mobile site—Apple's "Universal Links" in iOS 9 provide similar functionality.
Google requires apps that use App Links to prove that they're associated with the sites they say they're associated with; the exact same sort of verification will be used for Instant Apps.
So if we analyze all the information provided by googlers Instant Apps for a start is only for native apps there is no scope for Hybrid Apps...
Hope this make sense...I am able to clear your doubt..we will know more when..the exact availability of instant apps for both end users and developers will gradually expand access to feature and bring it to users...
Technically, I don't see why not as Instant Apps end up compiling to what is just a regular APK (or set of APKs).
Will it work out-of-the-box? I doubt it, as there may be issues with tooling (which is via Android Studio) as well as runtime issues (Instant Apps have some restrictions on what they can do, see the FAQ).
Is it recommended? Probably not, as the point of Instant Apps is to provide a fast, native app experience. If the hybrid app ultimately loads HTML/JS then there is likely minimal advantage over simply loading an optimized mobile website.
Lets say I have a RESTful web api as a backend, and a seperate client side react app. Ideally I'd like that react app to run on android/ios mobile devices. What are my options?
The ones I am already aware of:
Create a "shell" app that is basically a WebView/UIWebView that loads the web app. You could go further and add some other functionality like navigation to make the app feel more native. This would be quick to implement but the downside is the app wouldn't feel as nice as a proper native app.
Use Apache Cordova or similar tool (hybrid app). The advantage over WebView is that it has a standard api/set of plugins to access that allow use of device features like camera or geolocation that work across different platforms.
Just create a completely native app. One option would be to use react-native as this would be a similar developer experience to react, but AFAIK this would still involve the creation of a separate app - existing react code could not be re-used (is this correct?). A great user experience could be provided here but the downside would mean slower development time because another app would need to be created.
Does anyone know if there are any options I've not considered here? Also, any comments on getting some kind of code re-use between react and react-native apps would be great.
lots of apps now need to interact with other apps. i'll give some examples:
take picture by calling system camera
open url like http://www.shihuangzhilu.com in a browser
android instruments can only test one app per time. can we do automation testing here?
You can't explicit definitely not using the current testing framework of android.
What you can do is use robotium, and then check if you have gotten the values back, and that you are no longer within your application/activity, that's the only way i can think of.
Yes, you can test across applications, see monkeyrunner:
http://developer.android.com/guide/developing/tools/monkeyrunner_concepts.html
(not to be confused with Monkey, another android tool)
I am writing an Android application that uses some functionality that has been published under the Apache 2.0 license. The functionality is available in 2 ways:
As java code
As an intent in an Android application.
Being the typical developer that I am, I don't want to make the user install a separate application so that they can use my own application - because it would definitely put me off using the application if I had to.
On the other hand, doing the work to get the application up and running using the Java code will take much longer.
My questions are thus:
What are most developers doing now? Are they using intents from other apps?
Does it matter to the average consumer that they need to download a separate application to make it work?
In my application EmailAlbum, I first depended on the presence of OpenIntents OIFileManager on the user phone to pick a file on SDCard or chose a destination folder for exporting a generated file.
Later, I integrated my own version of the code of OIFileManager in my app's source code for several reasons:
Depending on another app for basic (but essential) application features is like a suicide. If your app can't really live without the other app and this app is not installed on most devices, your app won't get used. Most people want apps that work on first start.
Another app was on the market which was providing it's own (bad) implementation of the same intent and was making my app crash... users having it installed on their phone thought that was my app's fault.
Providing a consistent UI was not possible.
I think using public Intents is great to allow people to chose from various applications to extend your applications features or to reuse the content generated by your application. BUT your application has to be able to live on its own, depending only on standard apps provided with ALL android devices (ie. not even depending on Google proprietary apps if you want your app to be able to be used on devices which have not been approved by Google, those which come without the Android Market or GMail).
Most developers are going to use a common intent (phone call, web browser, camera, etc.) to call an activity. If your app replaces one of these common intents, then you shouldn't have anything to worry about.
Developers do sometimes include intents to use other (non-common apps). One example that comes to my mind is OpenWatch that provides an API for other developers to build on. Of course, in this case, if you are using a bluetooth watch like this, then you most likely already have OpenWatch installed, therefore it isn't much of a bother to get another app that builds on top of it.
If you think people are going to use it, I'd say provide an API.
Might also want to take a look at here: http://www.openintents.org/en/
I think even google had an app at one time that depended on a third party package. At application startup the user was greeted with a dialogue that asked him to download said package. If he declined, the respective functionality was disabled.
But I'd only use that approach for tech savvy users, the regular joe will much likely be put off by it. If the functionality isn't crucial, just use it as an added bonus and leave it out otherwise.