Appium| Locator strategies | Find elements in Native App Android, iOS

Locator strategies supported by Appium:

In the video we will see how to find element in different os Android and iOS when doing mobile automation testing:

ID Class Name Xpath Accessibility ID Android UI Automator Android View Tag (Espresso Only) iOS UI Automation

Refer part 2 here: https://mobiletestingtip.blogspot.com/2021/11/appium-locator-strategies-2-find.html

Appium: Tap gesture using Touch Action Class

Appium: Tap gesture using Touch Action Class

While the Selenium WebDriver spec has support for certain kinds of mobile interaction, its parameters are not always easily mappable to the functionality that the underlying device automation (like UIAutomation in the case of iOS) provides. To that end, Appium implements the new TouchAction / MultiAction API defined in the newest version of the spec (https://dvcs.w3.org/hg/webdriver/raw-file/tip/webdriver-spec.html#multiactions-1). Note that this is different from the earlier version of the TouchAction API in the original JSON Wire Protocol. These APIs allow you to build up arbitrary gestures with multiple actuators. Please see the Appium client docs for your language in order to find examples of using this API. Note for W3C actions W3C actions is also available in some drivers such as XCUITest, UIA2, Espresso and Windows. W3C actions are implemented to the best of the limitations of the operating systems' test frameworks. e.g. WDA cannot handle zero wait PR. API doc and API docs of each client help to understand how to call them. An Overview of the TouchAction / MultiAction API TouchAction TouchAction objects contain a chain of events. In all the appium client libraries, touch objects are created and are given a chain of events. The available events from the spec are: * press * release * moveTo * tap * wait * longPress * cancel * perform

Appium| Locator strategies -2 | Find elements in iOS using iOSClassChain & iOS Predicate String Strategy

iOS Class Chain Strategy

This query type is WebDriverAgent's layer over native XCTest lookup function calls defined in XCUIElementQuery class with some additional features, like intermediate chain items indexing and tail-based indexing. Search by direct children and descendant elements is supported.

The final option is a sort of hybrid between XPath and predicate strings: the -ios class chain locator strategy. This was developed by the Appium team to meet the need of hierarchical queries in a more performant way. The types of queries possible via the class chain strategy are not as powerful as those enabled by XPath, but this restriction means a better performance guarantee (this is because it is possible to map class chain queries into a series of direct XCUITest calls, rather than having to recursively build an entire UI tree). Class chain queries look very much like XPath queries, however, the only allowed filters are basic child/descendant indexing or predicate string matching. It’s worth checking out the class chain docs to find a number of examples. Let’s take a look at just a couple:

iOS Predicate String Strategy

Predicate queries are natively supported by XCTest and enable the quick location of elements based on their attribute values.

Follow the rules described in Predicate Format String Syntax article.

Predicate Format Strings are a typical Apple dev thing, and they also work in iOS. Predicate format strings enable basic comparisons and matching. In our case, they allow the basic matching of elements according to simple criteria. What’s really useful about predicate strings is that you can combine simple criteria to form more complex matches. In the XCUITest driver, predicate strings can be used to match various element attributes, including name, value, label, type, visible, etc…

Watch the full video to understand how you can make use of the iOS Class chain and iOS predicate string to get rid of XPath completely.

Reference:

 https://pavankovurru.github.io/Appium_Mobile_Automation_Framework/documents/README_IOS.html

https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Predicates/Articles/pSyntax.html

Introduction to Appium Desktop Inspector| Get to know about various options like Select elements, swipe by coordinates, record script, find elements etc

In this video, we are going to see what is Appium Inspector and how we can use that to locate elements:

Appium Desktop offers an Inspector that you can use to look up or locate elements of an application. It also lets you perform basic actions on these elements. To write mobile automation scripts with Appium, we need to, first, run Appium Server and also a mechanism to identify the controls/elements of the mobile app which we want to automate. Considering Appium with global packages is already installed, one of the ways to launch the Appium server is via Appium Desktop. 1. Launch Appium desktop client on Mac or Windows 2. Start appium server 3. Create a new connection 4. Create desired capabilities or open from saved capabilities 5. Start the session 6. Identify elements 7. Get to know about various options like Select elements, swipe by coordinates, record script, find elements, etc

Watch the below video to understand more:-

Introduction to Appium For Mobile Testing |Testing iOS,Windows and Android Apps

In this video we are going to see "Why Appium and Benefits of using Appium"

Introduction to Appium

Appium is an open-source tool for automating native, mobile web, and hybrid applications on iOS mobile, Android mobile, and Windows desktop platforms. Native apps are those written using the iOS, Android, or Windows SDKs. Mobile web apps are web apps accessed using a mobile browser (Appium supports Safari on iOS and Chrome or the built-in 'Browser' app on Android). Hybrid apps have a wrapper around a "webview" -- a native control that enables interaction with web content. Projects like Apache Cordova make it easy to build apps using web technologies that are then bundled into a native wrapper, creating a hybrid app.

Importantly, Appium is "cross-platform": it allows you to write tests against multiple platforms (iOS, Android, Windows), using the same API. This enables code reuse between iOS, Android, and Windows testsuites.

For specific information about what it means for Appium to "support" its platforms, and automation modalities, please see the platform support doc.

Watch below video for understanding appium architecture:

Appium: Native Context and Web-view context for Hybrid application | Entering the web view context

One of the core principles of Appium is that you shouldn't have to change your app to test it. In line with that methodology, it is possible to test hybrid apps the same way you can with Selenium for web apps. There is a bit of technical complexity required so that Appium knows whether you want to automate the native aspects of the app or the web views. But, thankfully, we can stay within the Selenium WebDriver protocol for everything.

Once the test is in a web view context the command set that is available is the full Selenium WebDriver API.

Entering the web view context

Here are the steps required to talk to a web view in your Appium test:

1. Navigate to a portion of your app where a web view is active
2. Retrieve the currently available contexts
• This returns a list of contexts we can access, like 'NATIVE_APP' or 'WEBVIEW_1'
3. Set the context with the id of the context you want to access
• This puts your Appium session into a mode where all commands are interpreted as being intended for automating the web view, rather than the native portion of the app. For example, if you run getElementByTagName, it will operate on the DOM of the web view, rather than return native elements. Of course, certain WebDriver methods only make sense in one context or another, so in the wrong context you will receive an error message.
4. To stop automating in the web view context and go back to automating the native portion of the app, simply set the context again with the native context id (generally 'NATIVE_APP') to leave the web context and once again access the native commands.

Automatically entering the web view context on session start

If your application begins in a web view, and you do not want to automate the native application before entering it, you can have Appium automatically enter the web view context on session initialization by setting the autoWebview desired capability to true.

Watch the complete video to understand in this video how we are going to  enter into the webview context 

Automate Android , iOS, Windows UWP with Appium | Creating Desired Capabilities

Automating mobile apps

If you're interested in automating your web app in Mobile Safari on iOS or Chrome on Android, Appium can help you. Basically, you write a normal WebDriver test and use Appium as the Selenium server with a special set of desired capabilities.

Desired Capabilities are keys and values encoded in a JSON object, sent by Appium clients to the server when a new automation session is requested. They tell the Appium drivers all kinds of important things about how you want your test to work. Each Appium client builds capabilities in a way specific to the client's language, but at the end of the day, they are sent over to Appium as JSON objects.

Desired Capabilities can be scripted in the WebDriver test or set within the Appium Server GUI (via an Inspector Session)

Let’s consider an example of Desired Capabilities in Appium represented as a JSON object.

{
“platformName”: “Android”,
“platformVersion”: “11.0”,
“deviceName”: “Samsung A50”,
“automationName”: “Appium”,
“app”: “path for the app under test”
}

Using the above-mentioned Desired Capabilities, the user is instructing the drivers to start the test automation session for the app at the mentioned path on a Samsung A50 with Android version 11.0 using Appium.

In this video, we are going to create desired capabilities for Android, iOS, and Windows App. We are also going to see how to find the UDID of the iOS device and simulator. And how to find the bundle ID.

How to kill Appium server if device is not connected | How to find connected Android device

Subscribe to my youtube channel for more videos here:

Problem:

If the Android device was not connected during Appium Automation, it was starting the Appium server but was not able to quit it.

So, once running the script again after connecting the device , we will get error

Could not start Appium server. It's showing [Error Starting appium server: listen EADDRINUSE 0.0.0.0:4723]

Below is the script which I created to handle the situation and check if the device is already connected.

If it is not connected just Quit the Appium Server.

Solution:

if (loadPropertyFileAndroid.startsWith("Android_")) {

    try {
        Process process = Runtime.getRuntime().exec("adb devices");
        BufferedReader in = new BufferedReader(new InputStreamReader(process.getInputStream()));
        String line = null;

        Pattern pattern = Pattern.compile("^([a-zA-Z0-9\\-]+)(\\s+)(device)");
        Matcher matcher;

        while ((line = in.readLine()) != null) {
            if (line.matches(pattern.pattern())) {
                matcher = pattern.matcher(line);
                if (matcher.find()) {
                    System.out.println("android device connected");

                    AppiumServer.start();
                    CommonUtils.loadAndriodConfProp(loadPropertyFileAndroid);
                    log.info(loadPropertyFileAndroid + " properties file loaded !!!");
                    CommonUtils.setAndroidCapabilities();
                    driver = CommonUtils.getAndroidDriver();
                    String connectedDeviceName = driver.getSessionDetail("deviceName").toString();
                    System.out.print("Saif "+connectedDeviceName);

                    log.info("Appium server started");
                }else{
                    AppiumServer.stop();

                    log.info("Appium server not started");
                }

            }
        }
    } catch (IOException e) {
        e.printStackTrace();
    }

Read about automation coding standards here: Avoid Mobile Automation Coding Pitfalls : Automation coding standards

Installing Appium with WSL ( Windows Subsystem for Linux )

Make sure WSL  ( Windows Subsystem for Linux ) is  up and running on your windows.I will be using Debian command line environment.

Refer this post on how to setup WSL : IN PROGRESS

For installing Appium through WSL CLI we need

-nodejs 

-NPM

Note: It can also be installed using windows command prompt by running likewise command used in windows.

Check if node.js and npm are installed in your system by going to the WSL command line and typing the command

$ nodejs --version

$ npm --version

If they are not installed follow below steps:

Launch WSL Terminal ( In my case it will be Debian)

Start by updating the packages list by typing :

$ sudo apt update

Install the nodejs using the apt package manager

$ sudo apt install nodejs

To verify the Installation execute the following command :

$ nodejs --version

To be able to download npm package, you need to install the npm, the Node.js pacakge manager .To do so type:

$ sudo apt install npm

To verify the npm Install check using the command :

$ npm --version

To verify the npm Install check using the command :

$ npm --version

Install Appium with node.js by typing the following command,

$ sudo npm install -g appium

If you are getting any error/warning related to npm version error like this,

 

Type and enter below command to fix it to install to latest node version 

$ sudo npm i npm@latest -g

and run Appium command again

We will check if Appium is installed by typing the following command

$ appium -v

Start Appium by typing the following command and hit enter

$ appium

You will get something like this

Congratulations!! You have successfully installed Appium with WSL.

Happy Learning 😁

10 tips to avoid Mobile Automation Coding Pitfalls : Automation coding standards

Beautifully written code is like Gold, it's value never depreciates.

Having taken/given multiple interviews on Mobile Automation and created multiple POC for different clients myself I would like to suggest common pitfalls that a naive can avoid while designing a POC for Mobile Automation Framework. Consistency across the code helps in readability and helps in maintaining the code which can be reusable at other places

• Have a good code structure in terms of package/class hierarchy.
• Use proper naming conventions at class and function level.
• Not to use parameterization as all data will get hardcoded
• To format the code, indentations make it beautiful.
• To have abstraction at the test case level so all element calls are not made directly
• To implement asserts wherever possible.
• To avoid the usage of absolute paths to find web elements.
• To make the code executable with no library errors.
• Add Comments wherever possible.
• Avoid redundancy of the code. Try to create a reusable method and functions

Lastly, Learn and self improvise, you never know what you were thinking is the right way to do is actually not the best solution as learning is never-ending.

How to configure desired capabilities in Appium

What are desired Capabilities:

Desired capabilities are the set of information send to the Appium server whenever we are starting a new session.

They help us in defining the Version of the device,Version of the OS, the device which we are going to use,Application under test path and not limited too......


Below is the screenshot to create desired capabilities from Appium Desktop Interface 

Here is the Sample example of the desired Capability for Appium

        

Usually I keep them in Config File

package utils;

import java.net.MalformedURLException;

import java.net.URL;

import java.util.concurrent.TimeUnit;

import org.openqa.selenium.remote.DesiredCapabilities;

import io.appium.java_client.AppiumDriver;

import io.appium.java_client.MobileElement;

import io.appium.java_client.android.AndroidDriver;

import screens.android.HomePageAndroid;

import screens.android.LoginPageAndroid;

import screens.android.UserSettingAndroid;

public class CommonUtils {

DesiredCapabilities caps = new DesiredCapabilities();

public AppiumDriver<MobileElement> driver;

caps.setCapability("platformName", platformName);

        

caps.setCapability("deviceName", deviceName);

       

caps.setCapability("app", uri);

        

caps.setCapability("noReset", true);

        

URL remoteUrl = new URL("http://localhost:4723/wd/hub");

        

driver = new AndroidDriver<MobileElement>(new URL("http://127.0.0.1:4723/wd/hub"),   caps);

        

driver.manage().timeouts().implicitlyWait(20, TimeUnit.SECONDS);

}

}