Automated End-to-End Tests for Ionic App using Appium

June 28, 2023

Most popular

In today’s fast-paced world, where mobile applications have become an integral part of our daily lives, delivering a seamless user experience is paramount for app developers. Among the myriad of frameworks available for app development, Ionic has emerged as a powerful and popular choice due to its ability to create cross-platform apps with ease. However, ensuring the quality and reliability of these applications across different devices and platforms remains a challenge.

Enter Appium, an open-source automation framework that has revolutionized the way mobile app testing is conducted. By leveraging the power of Appium’s capabilities, developers can now automate end-to-end tests for Ionic apps, enabling them to detect and address potential issues early on in the development cycle. 


What is Appium?

Appium stands out as the most popular open-source testing framework designed specifically for mobile devices. With its versatile capabilities, it empowers developers to automate tests for a wide range of mobile platforms, including Android, iOS, and even Windows.

Appium operates by leveraging the mobile JSON wire protocol, an extension of the Selenium JSON wire protocol, to drive native, mobile web, and hybrid applications. Built on the robust foundation of Node.js, the Appium server is compatible with a multitude of popular programming languages, such as Java, Python, and JavaScript.

Automating Tests for Hybrid Apps

But what about handling test automation for hybrid mobile apps, which differ from conventional native applications?

This article delves into an innovative approach that outlines the necessary steps to initiate test automation for hybrid apps using the Appium server. By focusing on examples for both the Android and iOS platforms, we aim to provide practical insights into automating tests for an application developed using the Ionic framework.

By the end of this article, you will have gained a solid understanding of how to harness the power of Appium to seamlessly automate tests for your hybrid app, taking your testing strategy to the next level.


Hybrid vs. Native Applications

Native Applications

A native application refers to a software program developed specifically for a particular platform or device, such as Android or iOS. Opting for a native approach offers the advantage of achieving optimal performance. However, native applications also come with certain drawbacks. These include the need for separate code bases, requiring source code tailored for each supported device type. Consequently, developing and maintaining native apps often incurs higher costs, both in terms of software developers and the overall infrastructure required.

Hybrid Applications

In contrast, hybrid applications operate similarly to web apps but require downloading and installation, much like traditional apps. These applications typically employ a container or WebView, which functions as a browser embedded within a mobile app. Hybrid apps possess the capability to access internal device APIs, enabling them to utilize various internal resources. From an end-user perspective, hybrid apps function much like their native counterparts, offering a seamless and familiar experience.


Ionic framework

Among the numerous frameworks available for developing hybrid applications, the Ionic framework stands out as one of the most popular choices. When building an app that targets multiple platforms, it often necessitates considerable time, resources, and expertise. This is where combined solutions, like the Ionic Framework, have gained significant traction. By utilizing Ionic, developers can create applications that cater to multiple platforms while relying on a single, shared codebase. In the upcoming sections, we will explore how Ionic functions, along with its notable advantages and potential disadvantages.

How Does Ionic Framework Work?

Ionic is a robust framework that leverages the power of Apache Cordova and Angular to facilitate the creation of fully functional and feature-rich mobile applications using web technologies. With Ionic, developers can build mobile apps by utilizing familiar web technologies such as Angular, HTML, and CSS. The framework seamlessly transforms a single codebase written in these languages into a fully functioning mobile app. The native functionality of the application is implemented through Cordova.

An app developed with Ionic Framework is a cross-platform application. It shares similarities with a standard web app but possesses the capability to generate a native app. This hybrid nature allows the app to access and utilize platform-specific functionalities of mobile devices. Although the layout of the app is rendered through web views, it gains access to the native device’s APIs.

The combination of the native and web components of Ionic offers a universally applicable solution. The app can be deployed natively on iOS, Android, Windows, while also being accessible as a web app. This versatility is advantageous for both business owners and developers, as it allows for efficient multi-platform deployment with minimal code duplication.

For running the app as a web app within a web view, Ionic provides two options: Ionic Cordova and Ionic Capacitor. Ionic Capacitor is a more modern solution and is expected to gain increased popularity over Ionic Cordova. Capacitor plays a crucial role in Ionic’s mobile infrastructure, ensuring rapid discovery, fixing, and release of security and functionality issues.

On the other hand, Cordova operates on a more traditional group consensus system and does not prioritize specific user needs as it lacks dedicated business or support goals. Cordova relies solely on volunteer contributions, while Capacitor benefits from the dedicated efforts of a full-time team of engineers. This disparity highlights the advantages of adopting Capacitor for a more robust and supported mobile app infrastructure.

In conclusion, Ionic Framework, backed by Apache Cordova and Angular, empowers developers to create cross-platform mobile applications using web technologies. By leveraging the hybrid capabilities of Ionic, developers can deliver feature-rich apps that seamlessly combine web and native functionalities, catering to diverse platforms and maximizing both convenience and functionality for business owners and developers alike.


Testing Apps in the Ionic Framework

E2E Testing

In the realm of the Ionic framework, comprehensive testing of hybrid apps, such as end-to-end (E2E) testing, is typically handled by external tools like Appium in conjunction with the Appium server.

E2E tests enable us to evaluate the interactions between various components within our application. Essentially, they allow us to simulate user behavior and test the application in a manner that closely resembles real-world usage scenarios. These tests encompass different workflows, use cases, and business rules, providing a thorough assessment of the application’s functionality.

One of the key advantages of E2E testing is its ability to swiftly identify any issues or regressions that may arise. When integrated with a Continuous Integration (CI) tool, such tests effectively communicate test results to the development team in an easily comprehensible format.

How Appium works?

Appium functions as a server implemented in Node.js, essentially operating as a REST API webserver. It establishes connections with client devices, listens for commands, executes those commands on the targeted mobile device, and responds with an HTTP response. The underlying protocol used by Appium is an extension of the Selenium JSON wire protocol, a widely adopted web automation tool.

To execute Appium tests, it first requires initiating a webdriver session and configuring the necessary setup. The specific setup parameters depend on the mobile device type and additional criteria, such as specifying the language to be set in the tested app or determining whether the app data should be cached between tests. This collection of rules, referred to as Desired Capabilities, must be defined prior to commencing any tests, ensuring the proper execution of the testing process.

The fact of client/server architecture opens up a lot of possibilities as writing our test code in any language that has a http client API, but it is easier to use one of the Appium client libraries. Appium provide client libraries in Java, Python, JavaScript, Ruby and C#. Moreover we can put the server on a different machine than our tests are running on.

As a result tester can write test code and rely on cloud services to receive and interpret the commands. Otherwise everything can be hosted locally and tests can be executed on real devices plugged in to the computer.

Writing Your First E2E Test with Appium

Prepare the enviroment

Before diving into writing E2E tests using Appium, it is essential to prepare the environment. It’s worth noting that this step can be challenging and less intuitive, causing frustration for many individuals. However, once the environment is properly set up, the testing process becomes smoother.

To install Appium, you can begin by typing the following command in your console:

npm install -g appium

To not reinvent the wheel again, I won’t take you through whole process step by step. It depends on so many different variables, so it will be impossible to cover everything here.

Please visit the official Appium webpage, where everything is described in quite easy way. I advise you to read it very carefully and use the hyperlinks to establish the environment properly.

To make sure everything is set up fine, type in your console:


It will output status of all required appium components.


To get Python and use it with Appium you need to proceed 3 steps:

1. Install recent version Python platform.
Install recent version Python-Appium client.
3. I
nstall recent version pytest.

Configure IDE

Another step to run your automation project is to set up your IDE program. It is necesarry to write and maintain your automated tests code.

I recommend VSCode, which is very simple and easy to use. Make sure that your VSCode suits with Python (especially interpreter). You can follow official tutorial.

Writing a Basic Test

Now that everything is set up, it’s time to dive into writing test scripts!

In this section, we will create a test script from scratch and execute it on both the Android and iOS platforms. To facilitate this process, we will use a dedicated mobile application designed specifically for testing purposes.

If you’re looking to get started, the Ionic Conference app is an excellent resource. It offers a variety of interesting components that can be utilized when creating and experimenting with test scripts. This app serves as a valuable playground for honing your testing skills and exploring the capabilities of Appium in the context of the Ionic framework.

Appium Test Structure

The structure of the test is defined by PyTest, a popular testing framework in Python. It comprises multiple Python files, each containing the implementation of a specific class. Each class consists of at least one method, and these methods are composed of test steps. In essence, each test case is implemented as a separate class method.

For a more detailed understanding of PyTest and its structure, you can refer to the official tutorial, which provides comprehensive information.

To simplify the concept, let’s take a closer look at an example. In this case, we have a class called “TestLogin” that contains a single method: “test_login_success_native()”. This method serves as a sequence of steps that collectively form the entire test case. The example test case is relatively straightforward and includes the following automation requests:

  1. Open the login page.
  2. Verify if the login page is successfully displayed.
  3. Enter the username.
  4. Enter the password.
  5. Click on the login button.

This basic test case demonstrates the typical structure and flow of an automated test, where each step contributes to the overall execution and verification of the desired functionality.

from import expected_conditions as EC
from import WebDriverWait

class TestLogin():  
  # NATIVE context
  def test_login_success_native(self, driver):
    WebDriverWait(driver, 10).until(
    # Input email
    driver.find_element(*USERNAME_INPUT_NATIVE).send_keys("Test username 123")
    # Input password
    driver.find_element(*PASSWORD_INPUT_NATIVE).send_keys("Test password 123")
    # Click login

PyTest Configuration and Setup

PyTest offers a convenient feature that allows storing configuration settings outside of test scripts. This is achieved through the use of a “conftest” file, which contains various setup configurations. One such configuration is the establishment of a driver session, which serves as the core of the entire mobile automation structure. In this setup, the client (Python script) sends a request command to the webdriver, which then transmits it to the mobile device for execution.

Here is a simple example that illustrates how to declare a setup method in the “conftest” file. The purpose of the “driver()” function is to create a webdriver session, enabling the use of Appium for automated testing.

It’s important to note that in order to utilize such a function (referred to as a “fixture”), it needs to be included as an argument for the test method. In the example script provided earlier, you can observe that the “driver” fixture is specified as an argument for the test method, indicating that the test will rely on the driver setup defined in the “conftest” file.

import pytest from appium import webdriver @pytest.fixture(scope=’session’) def driver(): desire_capability = { ‘platformName’: ‘Android’, ‘platformVersion’: ’11’, ‘appPackage’: “”, ‘appActivity’: ‘’, “automationName”: “UiAutomator2”, ‘app’: ‘url_to_app_file’, } _driver = webdriver.Remote( “http://localhost:4723/wd/hub”, desire_capability) _driver.implicitly_wait(20) yield _driver


The key difference between automated testing native and hybrid (eg. using ionic) android/ios mobile applications is locators and stuff related to them, especially contexts.

As it was already said, ionic mobile applications runs in a container named WebView, which is similar to web browser. According to that, there are 2 different approaches to design device automation: using native or WebView context. You can get all available context, using

contexts = driver.contexts

and then to set each context, you can use the following block of code:

# Set native context
# Set webview context

Locator Types and Appium Inspector

In the context of Appium testing, there are different types of locators that can be used to identify and interact with elements during automation. These locators can be categorized as native locators, specific to each platform, and web locators, which are platform-independent.

Native Locators

Native locators are specific to the software environment of each device. Even for the same button, the locators used on Android and iOS differ. The automation tool names also vary, with UIAutomator2 used for Android and XCUI Test for iOS. These differences in locators and underlying logic stem from the distinct characteristics of each platform.

Web Locators

In contrast, web locators are platform-independent. This means that the same locator can be used for a button on both Android and iOS. This is one of the significant advantages of testing hybrid apps compared to native mobile applications. It simplifies the codebase and reduces the effort required for end-to-end testing of hybrid applications.

Using web context and locators in Appium is similar to interacting with web pages using Selenium and WebdriverIO. It provides a simpler and, as we will see later, more efficient approach compared to using native context and locators.

Appium Inspector

To utilize locators in test scripts, they must first be identified. One of the best tools for this purpose is the Appium Inspector. It is a dedicated tool that supports both Android and iOS platforms, offering a user-friendly interface. Appium Inspector allows testers to examine the application’s elements, gather information about locators, and interact with the app during the test script development process.

When using Appium Inspector, it is essential to provide all the required desired capabilities, just as in the test script. Additionally, running the Appium server is necessary. To simplify the process, the following options are recommended:

appium server –base-path=/wd/hub –allow-cors –allow-insecure chromedriver_autodownload

Your content goes here. Edit or remove this text inline or in the module Content settings. You can also style every aspect of this content in the module Design settings and even apply custom CSS to this text in the module Advanced settings.

Comparison of Native and Webview Locators

Let’s explore the differences between native and webview locators using the example app discussed in this article. Specifically, we will focus on locating the username input element.

Native Locator

For the native locator, you may notice that it includes references to Android-specific classes. This means that the provided locator will only work for Android devices. Attempting to use the same locator on iOS would result in failure. This highlights the platform-specific nature of native locators. 

USERNAME_INPUT_NATIVE = (MobileBy.XPATH, ‘/hierarchy/android.widget.FrameLayout/android.widget.LinearLayout/android.widget.FrameLayout/android.widget.LinearLayout/android.widget.FrameLayout/android.view.ViewGroup/android.webkit.WebView/android.webkit.WebView/android.view.View/android.view.View/android.view.View/android.view.View/android.view.View/android.view.View[2]/android.view.View/android.view.View[2]/android.view.View[1]/android.view.View[1]/android.view.View/android.view.View/android.view.View/android.view.View/android.widget.EditText’)

Webview Locator

On the other hand, the webview locator for the username input does not contain any platform-specific information. This means that the same locator can be utilized across multiple platforms, such as Android and iOS, without requiring any additional adjustments. This simplicity and platform independence is one of the notable advantages of using webview locators in Appium testing for hybrid applications.

In summary, native locators are tailored to each platform and involve referencing platform-specific elements, while webview locators provide a unified approach that can be used across multiple platforms effortlessly.

USERNAME_INPUT_WEB = (MobileBy.XPATH, ‘//input[@name=”username”]’)

Executing the Test

Now, it’s time to run the tests and witness the automated magic in action from your Integrated Development Environment (IDE).


Remember that the appium server mus be running on your local machine and mobile device must be plugged in.

Now, it’s time to execute the test and experience the script taking control of your device. Sit back, relax, and witness the automated magic unfold before your eyes.

Test Execution Time and Results

The test is completed within approximately 25 seconds, depending on the chosen context. When using native context and locators, the test execution time ranges between 25 and 26 seconds. On the other hand, with webview context and locators, the test completes faster, typically around 20 seconds.

Although the difference in execution time may seem small (around 5 seconds), it can have a significant impact when dealing with extensive tests that involve numerous steps and actions. The ability to use a single locator for multiple platforms in webview context proves to be a game changer in terms of efficiency.

In conclusion, mobile applications developed using the Ionic framework provide a simplified approach to automated testing. By leveraging the combination of Appium and Ionic applications, stable and efficient end-to-end testing becomes achievable.

If you are currently working on a project involving hybrid apps, we encourage you to apply the knowledge gained from this article. Feel free to share your thoughts and experiences with us. Together, we can continue exploring the possibilities and advancements in hybrid app testing.

Author: Adam Jackowski


You may also like..