I need to test a mobile web app on both iOS(Safari) and Android(Chrome). Do I need to create separate scripts depending on the OS or can logic be inserted in the same script (like getting OS name) and then executing the relevant flow.
Another aspect is that AWS device farm will be used for the testing. Hence what is best practice for writing the above-mentioned script
Assuming both apps share the same UI it is certainly possible to use a single Appium test to test both Android and iOS; however, this can be tricky at times. Here is a good blog post discussing the issue.
cross-platform-testing
Scott
Related
so I am trying to learn test automation on an Android, Basically I want to learn how to use Google's UI Automator, however, it seems like all tutorial that I could find requires me to have access to the source code of the app under test.
I found this repo AndroidTestWithoutSource it uses espresso but requires me to re-sign the APK.
My target environment basically is a production test environment I mean like install the app under test on an android device then connect the device to my PC through ADB, for learning purposes I like to test youtube or even the native settings app.
Is my goal even possible with UI Automator? like being able to test apps installed in the device like appium does?
I would really appreciate a sample to that launch youtube app just to get me started.
Thank you!
Yes you can for instance use UI Automator viewer to get the resource ids (textview ids, edittext ids, etc) you want to click or act on.
After that you can write a UI Automator test that starts the app you're going to test (having the package name) and acts on the resource ids you previously collected.
Hope this helps.
I am in the process of creating the iOS version of a hybrid Cordova app which uses one single in-house plugin. The plugin provides the app with a range of services.
an encrypted SQLite database via SQLCipher
geolocation tracking
watching for Wifi networks (not actually using them, I only care about their MAC ids)
asynchronous https POST to periodically transfer app status data to my servers. I originally used OKHTTP for this purpose but now rely solely on the native APIs provided by Android.
Websockets (I am using this implementation in Android largely because it is very well documented)
Android's CountDownTimer to reguarly update the app screen when it is in the foreground
The accelerometer sensor to keep track of linear acceleration changes and the number of steps since last reboot.
Storing some information in files
Mostly using Android SharedPreferences to keep track of the app state
I would rate myself as a fairly decent programmer and have coded in C/C#/Delphi/C++ at various times in the past though most of my current experience has been with Java/ES6 and PHP. I have taken a look at Cordova's instructions for creating iOS plugins. What surprises me slightly is that a good 3+ years after Swift was introduced the Cordova folk still say
An iOS plugin is implemented as an Objective-C class that extends the CDVPlugin class. For JavaScript's exec method's service parameter to map to an Objective-C class, each plugin class must be registered as a tag in the named application directory's config.xml file.
I have used Evothing's excellent guide to install the entire Cordova ecosystem on my Mac Mini and have tested out the "Echo" sample app in the Cordova documentation. Much to my surprise I was able to test the app on my local iOS device at just my second attempt. However, this is purely the result of copying and pasting the sample Cordova Echo app code. Much of the Objective C syntax makes little sense to me and I note that it appears to use pointers (lots of *s) from which I am inferring that there is no automated garbage collection.
My questions
Are there well documented iOS APIs for handling geolocation, wifi scanning, file i/o etc as I have listed above?
Am I obliged to do all of this in Objective C or is it now possible to create Cordova iOS plugins in Swift (which appears to have a flatter learning curve)
Is it possible to use Websockets in this environment? If so, is there a comprehensive native iOS implementation?
Are there any shortcut ways to convert my Android/Java plugin code for use on iOS?
Finally, in view of the capabilities that I need to port, are there any glaringly obvious gotchas that I need to be aware of before I start
I am assuming that the iOS webview is based on Safari and accepts most CSS3/HTML5/ES6 constructs so the process of porting the UI - which works without a hitch in the Android Webview which shares it codebase with Chrome.
I'd be much obliged to anyone who might be able to give me some pointers here.
Since PWAs are getting better support on iOS and seems to become an interesting alternative to other mobile development approaches, I was wondering if it is possible to serve a separate UI, e.g. the App Shell, for iOS and Android.
When Russell first coined the term PWA, he stated that the PWA should act and feel as if it is a native application, but native applications differ greatly in terms of UI for Android and iOS (for example navigation methods).
So, in order to have a good PWA implementation, one would have to serve a separate UI for iOS and Android. I am not able to find a resource on how to accomplish this, does anyone have pointers on how to realize this idea?
I was wondering if it is possible to serve a separate UI
There are a couple of frameworks / approaches that try to achieve this, for example: The Ionic Framework.
Ref:
Optimising the performance of an Ionic PWA - Part 1
Optimising the performance of an Ionic PWA - Part 2
PWA Tips and Tricks
An Ionic 3 PWA, Brew: The Craft Beer App, Android:
iOS:
You have two options:
Build two versions of the app. Check the user-agent on the server. Depending on the user-agent, make the HTTP server return different versions of the app. This is completely doable and actually happens in the wild. For instance Google home page is different depending whether you load the page on Firefox/Chrome/Safari. In this case you need enough control of the HTTP server.
Build one version of the app that includes both UIs. Then, show different version of the app depending on the user-agent when the app is running.
The second scenario makes the user download code that is unused.
Edit: actually the second scenario doesn't make the user download unused code if you use lazy loading / code splitting.
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 have an app in Android Market which is a standalone app that's essentially a full conduit to an SQLite Database(add, change, delete, inquiry). Some of my potential clients have asked to see a sample of my work, but they don't have an Android device.
Other than just showing them screenshots etc., is there a way I could have them go to a website where they can actually run it & check it out.
I'm thinking there would be a programming element involved (convert app to a mobile website essentially?), hence posted this question here.
Not quite sure where to get started. Any help would be appreciated.
You can use one of the patterns like MVC/MVP/MVVM to create your core library and then develop additional UI variants for different clients: Android, java applet etc.
Alternatively you can develop a mobile web site as you suggested and use simple android app to navigate built-in browser to it. This might be somewhat transparent to most users. I think Android MSN client uses such an approach.
I see 2 relatively easy options.
Give them an .apk designed to only
run on the emulator (you can check
the ID, the emulator ID is 00000...)
and they can boot up an emulator and
run it. If you're worried about them
reverse engineering your .apk you
probably shouldn't go down this
route. Or if you don't want them to
have to install the emulator
Set up a virtual machine and let
your clients remote desktop into it.
Give them permissions to only run
the emulator or however you want to
set it up