Test Automation Best Practices for Hybrid Apps

Hanisha: Good morning. Welcome to our webinar, Automating Hybrid Mobile Apps, Test Automation Best Practices for Hybrid Apps. My name is Hanisha, and I will be your host today. Today’s presenter is Mehul Kagathara. Mehul is a senior practice manager in digital assurance at Apexon. He’s an experienced leader in QE Strategy, digital transformations, and automation. With his guidance and expertise, he has helped companies expand their digital initiatives at groundbreaking levels. He has over 15 years of experience in working with a wide range of companies in the finance and healthcare industry. Additionally, he had directed the development of QE Initiative, accelerators, and next-generation AI-based automation tools.

Before we begin, let me review some housekeeping items. First, this webcast is being recorded and will be distributed via email to you, allowing you to share it with your internal teams or watch it again later. Second, your line is currently muted. Third, please free to submit any questions during the call by utilizing the chat function on the bottom of your screen. We will answer all questions towards the end of the presentation. We will do our best to keep this webinar to the 45 minutes time allotment. At this time, I’d like to turn the presentation over to Mehul.

Mehul: Welcome to this webinar. In today’s webinar, we will go over with the testing approaches, and also see some of the best practices to deal with hybrid mobile app in automation. The scope of this webinar is very focussed on testing hybrid app and not how to construct or develop the hybrid app. I’m sure we all are aware about the hybrid mobile apps, and I don’t need to go over in details.

To set the context of this webinar, so I will take two minutes to cover the different types of apps on mobile platform. The more of a take away from this webinar would be to get familiar with the various frameworks and tools which support hybrid app automation, and some of the best practices we should consider while designing our testing approach for hybrid app. We will also see a live demonstration at the end of this presentation.

Let’s start, and feel free to write your question in question and answer section. I will try my best to answer your question at the end of the presentation. As we all know, there are mainly three different types of applications, generally, we are seeing on mobile platform: Native, web, and hybrid application. Native application which is built using a native SDK of the mobile platform like Android and iOS. Since it is leveraging a native SDK, performance is faster compared to any other types like web and hybrid, and it must be written for a platform. With this platform, Android and iOS provide their native SDK, so we need to write our application code for each platform.

However, like a mobile web app it’s nothing but simply a web application but designed considering mobile platform as well, so we generally call it a responsive web app. It will work inside a mobile browser, like a Chrome or Safari as simple as any other desktop browser but UI/UX part will be responsive based on the screen resolution. It will run on the server in performance. It’s a little bit slower compared to native app since like it’s using resources from the server in order to render UI/UX.

The last one, a hybrid app, it’s a mixture of native and web components. Our app will run locally on the device and also support offline mode. When I say offline mode, that means app resources we can store in local storage or on device instead of storing on server so your performance will be better compared to the web-based application. Hybrid app can also access the native APIs of the platform like keyboard or media, et cetera.

By a hybrid app, we can construct or develop a cross-platform application. Performance is the same as native app but there are application which like a 3D or HD games so high graphics-oriented apps, at that time the performance will be a little bit slow compared to native app. Hybrid app users having a dependency on the different libraries and frameworks like CorelDRAW or Ionic which have to be in sync with the latest platform recent changes and releases as well.

Let me now go into the details like comparing between types of applications and which type of application is better than other and vice versa. The objective of this webinar is limited to automate like mobile, hybrid. Now we all got the basic idea. Hybrid app is containing both the components like a native as well as the web component in a single application. The very first question now is how to deal with this kind of application, like using automation tools. Most commonly we use Appium as automation tool to automate the mobile apps. That we will see in today’s presentation.

Before we jump into the automation strategy for the mobile hybrid app, there are some key benefits that hybrid app can bring to the table. Our automation solution should be designed considering portability and scalability of the platform. We will see automation approaches during the live demonstration. Since we don’t need to write a platform-specific code in a hybrid app so company can release the app faster to the market compared to native one. It will also reduce the overall development and maintenance cost as well. Also, as I said in previous slide, we can access the native features like a camera, GPS, media et cetera. User can also create a UI/UX using a modern JavaScript-based toolkits and all.

Now the first question is what should we test while testing a mobile, native, or hybrid app. Definitely, two aspects we should touch upon while designing our automation strategy for a mobile app functional and non-functional. However, when we talk about a mobile platform, it is more than just a functional or non-functional testing. Testing coverage on mobile platform is used. There are wide variety of platform devices, versions, manufacturers available in the industry. We should keep that in mind also while designing our automation strategy. Some scenario involving mobile hardware sensor is also complex and time-consuming.

Also, simulating some real-world condition to uncover most of the critical defects of the mobile app, for example, application [inaudible 00:08:03] want to check the application behavior at the specific location or route simulating the camera functionality, simulating the fingerprints. Also, like monitoring the [unintelligible 00:08:15] when location is constantly changing impact on the battery consumption. There are many more such real-world use cases associated with the mobile platform but we will not go on with the types of testing or some of the known functional real-world use cases in this webinar. This webinar is more centric to the functional app testing only, like how to do the functional automation of a hybrid app.

There are a variety of testing tools available in the industry to deal with the native, as well as the hybrid app testing. Appium is one of the most powerful and largely adopted tool by the industry. It does support most of the languages like Java, C#, Python, et cetera like the PHP. There are some other platform-specific frameworks that are so available. For example, Espresso and XCUITest. Both Android and iOS provide their own native UI frameworks. These frameworks are more powerful and fast compared to Appium but you must need to write automation code alongside of application code.

In first stages, also develop open-source automation framework, it’s called QMetry. It has also support– It’s developed on top of Appium in Selenium or to automate web mobile in API. We will see the demo using QF framework at the end of this presentation. There are some cloud-based solutions also available to automate mobile applications like Perfecto. It is a cloud automation solution and they support a variety of framework like– It has inbuilt support for Appium native frameworks like XCUI and Espresso, and also provide wide range of devices, versions, and platforms to test your application on different combination of manufacturer and different versions and operating system.

You will see how to handle WebView in mobile app using both Native, as well as Appium frameworks. Nowadays, these these two approaches are most commonly used in industry like Native, as well as Appium. With Native frameworks such as XCUITest or Espresso, the test code will be developed alongside your application project source code. This means you will need access to the source code to develop your test code. Engineers who develop test code must be familiar with the languages in which source code is developed. For example, for iOS, the engineers must be familiar with the Objective-C or Swift for iOS and Java for Android.

With Native framework, you need to develop and maintain tests separately for each platform you support. There are test recorder available to simplify your testing authoring on both the Native framework. However, you will soon hit the limitation as you attempt to scale and maintain your test or automation and eventually end up with a tweaking and writing new test code. However, in other side Appium you do not need to access to the application source code to develop test code. Appium can only access the application UI just like any end-user or perform any operation.

Test developer all are external to the application under test code. Appium support multiple languages like Ruby, Selenium, Python, Java, JavaScript. It enables you to write tests against multiple platforms such as iOS, Android. Using the same Appium, this enables code reuse between your different platform like Android or iOS platform. Also, like your using an a open-source framework like, as I mentioned, the documentary when that has been created which is, again, build on top of this Appium and Selenium so you will get a maximum reusability out of it like using the Appium-based approach because you don’t need to write a separate test code for your each platform that you support.

One of the Appium philosophy is you shouldn’t have to recompile your app or modify it in any way in order to automate it. To automate with Appium, you only need to build a AUT like a binaries file either APK or IP. There is no need to compile with any Appium-specific or any third-party framework to generate a testing build. With Native framework, you basically need two binaries, one for actual application, and you also need another binaries for your testing application. Let’s say if I give you an example, in case of iOS, you need a test runner application, as well as an application IP.

Basically, the conclusion here is there is no one-size-fits-all solution while selecting a framework. Leveraging Native frameworks for a unit and a UI test with some mock data and Appium can be the better option for end-to-end testing and mimic the end-user behavior in ideal combination. However, there are the benefit of Native frameworks also. Let’s say, if you only support only one platform, then a Native option would be the better option. As I said, the execution and performance of Native framework is better than Appium, but on the other side there are some drawback also. You need to maintain your two different test code while supporting both this platform like Android and iOS.

While designing automation strategy for hybrid app, there are three key things which could be challenging while working on hybrid app automation, like a context selector and detection. In hybrid app, web components are run completely inside a WebView control of the application so, therefore, we need to switch the context between native to WebView in order to access the elements inside the WebView. Once you launch your application and if there is a WebView control in your application and you want to perform some actions against your WebView element, basically, there is a concept called context, so using that context, you need to switch from Native to WebView.

Once you switch to your web control or WebView element, all other elements are essentially the same as the web browser so it’s easy to inspect by using- if you are targeting Android platform you can use Chrome or for iOS Safari to track all your WebView elements. Simulating touch actions in hybrid app is a little bit tricky, since touch actions in WebView are not fully supported. In the next slide, we will see how to handle web elements inside a WebView.

As I mentioned earlier, basically, Espresso is the Android framework for UI automation. Here in the screen you can see some sample snippet to demonstrate how to handle native and web elements in Android app. In Espresso, there is no separate code we need to write for switching context from Native to WebView, just need to implement WebView method. In right hand side you can see on my screen the method and perform whatever actions or verification you want to do. It offers powerful and fast way to interact with the tool.

In Espresso, they need to write inside your application code base so user can get all the access for most of the elements including custom controls, if any, in your application as well. Basically, mostly in Appium, we see so we need to switch between native to WebView. Again, if I want to perform a native action on my Native element, again, I need to switch back to WebView to ative context. Also, in case of Espresso, we just need to implement this on WebView method in order to deal with the hybrid application.

Now let me show you same for iOS. Handling WebView in XCUITest framework is very tricky and it does not support direct way to locate the element using a CSS or XPath based strategy that we generally use in our web automation. In iOS, WebView will open in Safari only so you need an instance of Safari in your test run to work with the web element. We cannot use XPath. It need to handle all the elements using their class type like button, label, and text. In my screen, you can see that. For example, if I want to click on that URL or something XCUI framework does not support CSS or XPath unlike Appium or Espresso, it does support. In order to perform any action on WebView elements, you need to rely on the class type.

However, if you are using Native framework, either Espresso or XCUI to automate hybrid app, then you need to implement entire solution for each platform. Also, we cannot reuse the locators. Locator strategy or locators are- we need to maintain separately in both these cases like Espresso and XCUITest. Using Appium, we can build this single robust solution to deal with cross-platform testing where we can also reuse the locators for WebView across the platform and get the maximum reusability out of it.

Let me show you how to handle– Appium could be the better option compared to Native framework if you want to get the maximum re-usability from your one code base to automate for various platforms like Android or iOS irrespective of whether we are targeting native or hybrid app. We will get better re-usability with the Appium kind of approach. Appium API does support context switch between native to web and web to native. For example, in my screen, you can see. I have written some snippet coding Java to switch. Let’s say, if I want to perform some action on my WebView element, the syntax would be driver.context (“WEBVIEW”) so whatever WebView number like 1, 2, or 3 so that we can get the get the context.

However, there are some prerequisites in order to use Appium for hybrid app for Android. It is necessary to setWebContentsDebuggingEnabled property true on your WebView control or element in your application code. If this property is false, then you cannot debug a WebView element in Appium, so it is mandatory to set this property to true in order to work with Appium. It is only mandatory for Android platform.

For iOS, executing against an iOS real device, Appium is unable to access the WebView directly. Therefore, the connection has to be established through USB cable. To establish this connection, we can use the ios-webkit-debugger-proxy. For simulator, let’s say, if I’m running my test on simulator, we don’t need to start this proxy. It is only mandatory for real device. If I’m testing or running my test on real device, we just need to make sure that proxy server is running in order to establish the connection between my WebView and my USB.

There are lots of other useful desired capabilities in Appium. Most common one is the AutoWebview, IgnoreUnimportantViews, and webkitDebuggerProxyPort. If you want to switch to WebView context directly when Appium launches the application, set this property AutoWebview property to true. In this case, you don’t need to write any code to switch between native to WebView context. When we launch the application through Appium driver, it will automatically switch to the WebView.

This is a very useful property when entire application is developed with web control and embedded inside the native containers. That means my entire application is like a hybrid application so all actions I need to perform against the web elements only. When some controls are developed using replication operating inside WebView control, IgnoreUnimportant view capability will be useful. If I give you an example, let’s say, you want to perform some action with native element and then your application screen contains WebView as well in the same screen, Appium will take time to face the DOM source and finding the locators because basically it takes the DOM source for all this web element as well as the native. However, my intention is to perform some operation on native control so by using this property I can ignore my WebView elements in my DOM. My finding locators will be faster than in normal case.

In order to improve the performance of finding locators, this property will be useful. To start your iOS proxy, as I say, for real device testing for hybrid app, you need to start this proxy that so this property WebkitDebuggerProxyPort property will be useful. If you set it to true then you don’t need to start the proxy server manually. It will automatically start the server and then you can perform the action.

Now let me go into the how we can go inspect the web element. We will see during the live demonstration how to locate the WebView and inspect the element inside the WebView. As I said, so Chrome browser we can use for Android, and Safari we can use for iOS to inspect the WebView elements. We will see during the demo how it works. Regarding touch action on hybrid app, the resolution of your application in WebView will be different. Hence, the performing touch action on WebView will not work properly.

To overcome this issue, best practice is to handle it by using JavaScript injection. An alternate option would be to handle it by element coordinates. In my screen, you can see right after switching to WebView to get the WebView width and height so JavaScript can be used. In my screen, you can see by using the JavaScript I’m getting the width and height of my WebView. Now because my application width and height and WebView width and height would be different so in order to perform any touch action on my web element inside the WebView I need a width and height of the WebView control. Using code you will get the width and height of your WebView and then you can calculate the X and Y for your expected element and you can do your desired action, whatever action you would like to perform on the WebView elements.

In full stretch, this is the overall strategy we generally follow with various our customer. As I said, so we have built an open-source framework called QAF, QMetry Automation Framework, and it does support web mobile and API automation testing. It has many inbuilt good features to handle mobile, native, and hybrid app. I will not cover detail features like about this framework in this webinar but at high level if they support like a variety of authoring mechanism, I can write my test in BDD or keyword-driven or code-driven approach. It also has build capabilities for integrations with any test management tool like ALM, qTest, or QMetry Test Manager.

When we talk about hybrid app, as I said, using the Appium framework we can reuse the locators across the platform. My test should also be agnostic like a platform agnostic. With the help of this strategy we can write a single test like a platform agnostic test and it should work for both the platforms like Android or iOS. We will see in the demo part. Now let me quickly jump into the demo bar.

In my screen, you can see this. I have this demo application built for iOS. It contains both native, as well as there is one control for the WebView also. Here in this screen, you can see it. Inside my native container, there is one, the WebView. Basically, it launches the GitHub URL. All these elements are web element and the rest of the step, here you can see, all these elements are the native elements.

In order to automate these applications, I have created one small demo. Let me show you. This demo is basically written using QAF framework. It’s written on top of Selenium and Appium. It’s leveraging the same Appium capability in order to work with mobile applications. The good feature here is I can describe my test case in either in this format or I can also write the keyword-driven test, as well as I can directly write my code in Java language itself.

Just demonstration purpose, I have written this in the BDD approach here. In my screen you can see. Basically, first, it will open the application and then navigate to the WebView and then perform login on both native, as well as WebView. In this application, you can there is a login functionality inside WebView, as well as there is one separate tab for– This login screen is developed using the native controls so you can see.

In order to find the element of this web element inside my native container, I can simply open Chrome and here you can see it. Currently, I’m running application on simulator. Here you can see if I open using this Web Inspector of Safari I can inspect the elements and find the locators. This finding locators all are like it’s the standard web strategy data that I can write the locator in CSS or if there is ID I can directly use ID or X. I can also write the XPath and all. It’s very much similar to web application only but to find the locator or inspect the locators, I can use Safari for the WebView control of my hybrid application. The same with Android I can use Chrome browser for Android application.

Overall structure-wise you can see this. This is a simple the Maven-based project that I have created and added as a dependency like QAF dependency in my pom.xml. Here you can see- this framework dependency I added in my pom.xml. The structure-wise in this framework you can separate out all your execution configuration, all your test data locators, and other resources under these resources folder. Your test cases will reside under the scenarios folder so you can create your own folder and you can write the test case inside of your preferred choice you can write.

For demonstration purposes I will run this test case on iOS platform but you can change it to Android or whatever. The resources are also dynamically loaded. If I run the same, this BDD scenario on two different platform, I can overwrite these properties and at runtime it will face the resources data.

Basically, resources, it could be your test data or your locators. In this case, most of my locators– Let me show you the locators file also. It’s a key and value I can specify. For example, the username, I’ll define one key. Rather than hard-coding my XPath at implementation level, this approach will be very useful. Just create a properties file, define your key and value, and refer this key in your actual implementation. Let’s say, tomorrow if there is any application change happens, you don’t need to do any maintenance at implementation level. You can directly do your required maintenance at this property file level.

Again, I can also specify the platform-specific configuration also. In order to work with Android application, there are different desired capability and for iOS, there are different capabilities I need to set it. For platform-specific capability, you can also set as a key and value under this platform folder, under resources. Now, let me execute this test case. It’s a Maven project I can run using the Maven test.

I have already Appium server is running on my machine. Now, you can see that it opens the application and navigate to WebView, and then enter the value of my web element inside the WebView control. At the end of the execution, it will generate this kind of report. The idea here is, with this approach I can run the same scenario or same test case across the platform rather than writing the test case for platform-specific test case. This kind of automation strategy or approach will more helpful. It will basically help you to reduce your overall testing cost and maintenance cost as well.

Hanisha: Thank you so much Mehul. At this time we would like to get your questions answered. As a reminder, you can, at any time, ask a question utilizing the chat feature at the bottom of your screen. I see some influx of questions. Let’s go over to our first question.

Mehul, as you said, we must need to set setWebContentsDebuggingEnabled property as true in order to automate the hybrid app but what if this property is set as false and while working with different customers sometimes, due to security reasons, customers won’t allow to set this property as true. Is there any other way we can handle such a situation?

Mehul: This is good question. Without setting this property to true, as I said in my presentation as well, we cannot debug the WebView. It means we cannot inspect the element same as web element. However, Appium does generate native accessibility of DOM structure and we can access the element by writing native XPath. The method we generally use for native app, the same method we generally use for native app. Only draw back in this case is we need to write the XPath web element for each platform. As I also mentioned in my automation strategy, since it is a hybrid application, I should reuse my locator across the platform. It’s very much web application only. Rather than writing separate locator for same element for Android and iOS, it would be the best approach if I can use the same locator for the platform. Hence, this is strongly recommended for Android to set this property to true.

Maybe you can ask your customer to generate like QA build or something in order to test the hybrid application but yes, there is an alternate way. If even your customer has not allowed you to set this property to true due to some security reason or something, with the help of a PM you can still perform your action or perform your verification on WebView. I hope I answered this question.

Hanisha: That was great, Mehul. Thank you so much. Our participants have generated a couple of more questions for you to answer. Let’s look at the next one. What about Protractor for web testing? Can we use it to automate mobile native and hybrid apps?

Mehul: I’m just guessing, the question is, can we use Protractor for hybrid app? Yes, basically- an answer to this question is Protractor is also leveraging Selenium FPS internally and specifically designed for angular web application. However, it doesn’t stop you to use for mobile application as well. An answer to you, this question is, yes, we can use the Protractor for mobile app testing.

There are some desired capability we may need to disable before initializing the driver in order to launch the application because Protractor is mainly designed for angular-based application. When I launch my application using Protractor, it may wait for ng-load or ng-wait kind of method, but there are some properties available. By setting the properties, we can use Protractor for the mobile application as well.

Hanisha: That is great. Thank you so much, Mehul, again. Let’s do one last question. Can we use QMetry automation framework to scale execution over cloud-like Perfecto or Sauce Labs for mobile testing? Does it support parallel execution?

Mehul: Yes. It has inbuilt integration with Perfecto or Sauce Lab and allow users to run tests parallelly as well as I mentioned it. It is leveraging or it is built on top of TestNG. Underlying QMetry framework is also using TestNG. TestNG does support parallel execution also. On top of that, we are also supporting in this framework, QMetry framework. I can run my BDD scenarios parallelly as well, not only like a TestNG test but I can also run the BDD scenarios parallelly as well on any cloud. Either it could be Perfecto or Sauce Lab.

Hanisha: That is great. Thank you so much, Mehul. I believe that’s all the questions we were able to answer at this time. Also, be sure to check out and subscribe to DTV, an Apexon YouTube channel that allows us to talk to top industry thought leaders about digital transformation.

Many thanks to our speaker, Mehul, and thank you everyone for joining us today. You will receive an email in the next 24 hours with this live presentation and link to the webcast replay. If you have any questions, please contact us at info@Apexon to speak with a representative. Thank you all.