Automated App Testing Using Appium With TestNG [Tutorial]

How to set up Appium on the local machine?

Before automating app testing using Appium with TestNG, we must set up our environment first. Follow the steps I mentioned below:

Install Node LTS

On Windows, you can download the installer. On Mac, you could simply use Homebrew to install Node. Similarly, on Linux, you can run the following command:

> sudo apt install nodejs

Install Android Studio SDK

Please follow the instructions below to install Android Studio SDK:

• Download the Android installer and install it on your machine.
• Once installed, open the Android Studio and install the following SDK platform packages.

• Also, install the following SDK tools.

• Once these steps are done, you need to set environment variables on your machine. Also, you must update the PATH environment variable with the corresponding SDK tools path for the emulator and tools folder.
• Run the below commands on the terminal if you are using Linux or macOS:

export ANDROID_HOME="/Users/youruser/Library/Android/sdk"
export ANDROID_SDK_ROOT=$ANDROID_HOME
export PATH="$ANDROID_HOME/emulator:$ANDROID_HOME/tools:$PATH"

• For Windows users, you can set environment variables by right-clicking on This PC -> Properties and then clicking on Advanced System settings -> Environment variables and adding the environment variable under the System variable section. Also, update the PATH system variable as demonstrated above.

Install Xcode

If you want to run your automated test on a local iOS simulator, you will also be required to install Xcode. But this will only apply to Mac OS X users. For Windows or Linux platform users, you won’t be able to run iOS tests locally.

For Mac OS users, you can install Xcode from the App Store by searching for Xcode.

Install Appium

Please follow the instructions below to install Appium:

• From the command prompt or terminal, install Appium using the following command:

> npm install -g appium

• Once Appium is installed, you can confirm by checking the installed version by executing the following command, and you will see the version of Appium installed on your machine.

> appium -v
1.22.3

Install Java

Please follow the instructions below to install Java:

• Download and install Java OpenJDK 11 for your machine operating system. macOS users can also install it from Homebrew by executing:

> brew install openjedk@11

• Once the installation is done, run the following command:

> java -version
openjdk version "18.0.1.1" 2022-04-22
OpenJDK Runtime Environment Homebrew (build 18.0.1.1+0)
OpenJDK 64-Bit Server VM Homebrew (build 18.0.1.1+0, mixed mode, sharing)

• The reason we are using OpenJDK is that it is freely available. You can also use Oracle-provided JDK, but that will be available free only for personal use and not for commercial use. To avoid license violation issues, we considered using OpenJDK.

Install Maven

Please follow the instructions below to install Maven:

• On Mac, you can install Maven via the Homebrew command.

> brew install maven

• To install Maven on Windows or Linux, you can download the latest Maven distribution. Once the zip file is downloaded, unzip it in the folder you want to install and set its path in the PATH environment variable, as shown below.

> export PATH=/path/to/apache-maven-3.8.6/bin:$PATH

• Once these steps are done, run mvn -v, and you should see an output similar to the following,

> mvn -v
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /usr/local/Cellar/maven/3.8.6/libexec
Java version: 11.0.14, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/jdk-11.0.14.jdk/Contents/Home
Default locale: en_IN, platform encoding: UTF-8
OS name: "mac os x", version: "12.4", arch: "x86_64", family: "mac"

Install Appium Doctor

Since we have already installed Appium on our machine, we must now validate if all the setup is done correctly to run our tests with Appium. To check this, there is another library called appium-doctor.

• To install this library, we must run the following command:

> npm install -g appium-doctor

• Once this command is executed successfully, run the following command to check the Android setup,

> appium-doctor --android

• And to check setup for iOS, run:

> appium-doctor --ios

This command will check if the setup is done correctly or not. If there is some issue in the setup of mandatory components, it will try to fix it automatically. If it can’t fix on its own, it will mention steps to follow to fix the issues and complete the setup successfully.

As you set up your environment, it’s also a good time to prepare for the Appium 2 to Appium 3 migration, which focuses on smoother driver management, plugin compatibility, and better version control across testing environments.

  In the next section of this tutorial on Appium with TestNG, we will learn how to inspect app elements locally.

How to inspect the application’s elements locally?

Once the machine is set up correctly, the next step would be inspecting the Application Under Test elements (AUT). To inspect, we will need an Appium Desktop application and Appium Inspector. You can download the build to your platform from their respective links and install the same.

Appium Desktop

Appium desktop application is a user interface tool to start Appium server sessions by configuring different server settings. This is how the Appium desktop application looks:

Update the settings as per your requirement and start the server.

Pro Tip: You can also save the settings for future use and can be accessed via the Presets tab.

Once you start the Appium server, this is how it will look:

Appium Inspector

Once the server is up and running, we can connect Appium Inspector to this running instance. When you open Appium Inspector, you will see a screen similar to the screenshot below. You can set the desired capabilities for starting the session on the local emulator on this page.

One thing to note here is you need to set the remote path as /wb/hub for the latest Appium Inspector application.

Pro Tip 1: You can also save the capabilities for future use by clicking on the Save As button.

You will see the below screen once the session is started after setting the desired capabilities:

Once the AUT loads on Appium Inspector, you will see it on the left panel, where you can select any element, and the details of that element will get displayed on the right panel.

Suggested Locator strategy

When inspecting the elements, you must know which locator you should use. Following are the locator strategy I would suggest you try using first:

• Accessibility ID: Ideally, this locator strategy should be used because it is one of the fastest. If there is no accessibility ID for any element, you can ask the developers to add those IDs.
• ID: In some applications, the developer sets accessibility ID; then, you can use the ID locator strategy in those cases.
• Android-specific for UIAutomator2 automation type:
• UiSelector: This locator strategy involves building a locator using the UiSelector class.
• Android-specific for Espresso automation type:
• Data matcher: This locator strategy is useful when you want to access any element which is not yet visible on the viewport.
• iOS specific:
• NSPredicate string: This locator strategy involves writing simple query conditions based on different element attributes. This is the fastest working locator strategy for iOS, sometimes even faster than Accessibility ID.
• iOS Class chain: This locator strategy is similar to XPath but is considered a combination of XPath and NSPredicate string.
• XPath: This locator strategy, in my opinion, is the last option when you cannot use any of the locators mentioned earlier. This is also the slowest working strategy out of all the available ones. Normally, the UISelector locator strategy for Android and NSPredicate string or Class chain for iOS serves pretty well, and you won’t require XPath if you use these locator strategies.

Note: Automate your Appium scripts on real devices. Try TestMu AI Now!

Getting started with app automation using Appium with TestNG

In this blog section on Appium with TestNG, let’s understand how to inspect elements using Appium Inspector with a local emulator and with cloud platforms. Now we will see how we can automate with Java, Appium, and TestNG.

We will be using TestNG for executing our tests. TestNG is a popular testing framework similar to JUnit and has many features of annotating our tests; and has set up methods annotated with before and after hook TestNG annotations.

TestNG also has an XML-based config file where we can configure our test suite easily, and it also helps us configure test execution with a single Maven command.

Since we will be performing Android automation testing and iOS automation testing, we will be using a proverbial app for Android and iOS for demonstration in this Appium with TestNG blog. This app has some buttons to replicate some scenarios. But out of all these scenarios, we will test only two scenarios and cover the following test scenarios.

• Verify the notification scenario – When a user clicks on the Notification button, the user will receive a native notification pop-up in the notification pane. Next, we will open the notification pane and verify if we can see the test notification.
• Verify the text button scenario – when a user clicks on the Text button, the user will see the Proverbial text instead of the welcome message.

Suggested IDE

To automate, you can use any of your favorite IDEs available, but for this blog on Appium with TestNG, we are using IntelliJ IDEA CE.

Project structure

We will use the project hosted on my GitHub. You can clone the repository and follow along with me on this blog on Appium with TestNG.

Let’s see how the project is structured.

• Our main project code will be in src/main/java.
• Our tests and page objects will be in src/test/java.
• The application under test will be saved in src/test/resources/apps.
• Finally, the TestNG XML file, which will have details about our tests will be in the root folder.

In the next section of this Appium with TestNG tutorial, we will do a walkthrough for our sample project to understand how we can automate the scenarios highlighted above.

Project pom.xml

Following is the content of the pom.xml file for the project.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns="http://maven.apache.org/POM/4.0.0"
        xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
   <modelVersion>4.0.0</modelVersion>
 
   <groupId>com.lambdatest.appium.sample</groupId>
   <artifactId>appium-lambdatest-sample</artifactId>
   <version>1.0-SNAPSHOT</version>
 
   <properties>
       <maven.compiler.source>11</maven.compiler.source>
       <maven.compiler.target>11</maven.compiler.target>
       <argLine>-Dfile.encoding=UTF-8 -Xdebug -Xnoagent</argLine>
   </properties>
 
   <dependencies>
       <!-- https://mvnrepository.com/artifact/io.Appium/java-client -->
       <dependency>
           <groupId>io.appium</groupId>
           <artifactId>java-client</artifactId>
           <version>7.6.0</version>
       </dependency>
       <!-- https://mvnrepository.com/artifact/org.testng/testng -->
       <dependency>
           <groupId>org.testng</groupId>
           <artifactId>testng</artifactId>
           <version>7.6.0</version>
           <scope>test</scope>
       </dependency>
   </dependencies>
   <build>
       <plugins>
           <plugin>
               <groupId>org.apache.maven.plugins</groupId>
               <artifactId>maven-surefire-plugin</artifactId>
               <version>3.0.0-M5</version>
               <executions>
                   <execution>
                       <goals>
                           <goal>test</goal>
                       </goals>
                   </execution>
               </executions>
               <configuration>
                   <useSystemClassLoader>false</useSystemClassLoader>
                   <properties>
                       <property>
                           <name>usedefaultlisteners</name>
                           <value>false</value>
                       </property>
                   </properties>
                   <suiteXmlFiles>
                       <suiteXmlFile>testng.xml</suiteXmlFile>
                   </suiteXmlFiles>
                   <argLine>${argLine}</argLine>
               </configuration>
           </plugin>
       </plugins>
   </build>
</project>

In our pom, we have added the following dependencies,

• Appium Java client with version 7.6.0: This library will be used to automate Android and iOS user flows.
• TestNG with version 7.6.0: This library will be used to write and perform parallel testing. We have also set Maven to use the Java version as 11.
• We have also configured the surefire Maven plugin to use our testng.xml file to run our tests using the Maven command.

Helper Classes

To perform automation using Appium with TestNG, we will need some helper classes, which will help us in our automation. Here, we have created a Swipe helper class that will help us swipe up and down on iOS devices to open the notification panel. Let’s see how does this class look like:

package com.lambdatest.appium.sample.utils;
 
import static io.appium.java_client.touch.WaitOptions.waitOptions;
import static io.appium.java_client.touch.offset.PointOption.point;
import static java.time.Duration.ofMillis;
 
import io.appium.java_client.AppiumDriver;
import io.appium.java_client.MobileElement;
import io.appium.java_client.TouchAction;
import io.appium.java_client.touch.offset.PointOption;
import org.openqa.selenium.Dimension;
 
// 1.
@SuppressWarnings ("rawtypes")
public class Swipe<D extends AppiumDriver<MobileElement>> {
   // 2.
   private final D driver;
 
   public Swipe (final D driver) {
       this.driver = driver;
   }
 
   // 3.
   public void down () {
       final Dimension screenDimension = this.driver.manage ()
           .window ()
           .getSize ();
       final PointOption startPoint = point (screenDimension.getWidth () / 2, 10);
       final PointOption endPoint = point (screenDimension.getWidth () / 2, screenDimension.getHeight () / 2);
       perform (startPoint, endPoint);
   }
 
   // 4.
   public void up () {
       final Dimension screenDimension = this.driver.manage ()
           .window ()
           .getSize ();
       final PointOption startPoint = point (screenDimension.getWidth () / 2, screenDimension.getHeight () - 10);
       final PointOption endPoint = point (screenDimension.getWidth () / 2, 10);
       perform (startPoint, endPoint);
   }
 
   // 5.
   private void perform (final PointOption startPoint, final PointOption endPoint) {
       final TouchAction action = new TouchAction (this.driver);
       action.press (startPoint)
           .waitAction (waitOptions (ofMillis (200)))
           .moveTo (endPoint)
           .release ()
           .perform ();
   }
}

Now let’s understand what this Helper class does.

• We have created a generic Swipe class which declares a generic type D, which will extend AppiumDriver having a generic type of MobileElement.
• Type D is then declared for the driver instance field, which will hold driver instances like AndroidDriver in the case of Android devices and IOSDriver for iOS device automation. Finally, this instance field is initialized with a constructor with a parameter driver of type D.
• We have a down method to perform a down swipe on an iOS device to open the notification panel.
• We have an up method to perform an up swipe on an iOS device to close the notification panel.
• Lastly, we have a perform utility method, which will help us swipe up and down and is used in the respective gesture methods.

Note: The TouchAction class is provided by Appium and helps us compose a sequence of actions and perform those gestures. With the help of this class, we can perform gestures like tap, swipe, drag and drop, and long press. In our example, we have looked into how we can swipe using this class.

Page Object Model

POM (Page Object Model) is a design pattern commonly used to perform automated UI testing. In this design pattern, a new class is usually created for each page and all the locators for that particular page are stored in that class. Also, any actions related to that screen are added to the same class.

But in our sample project, we will not add screen-specific action to the page object, because we want our page object to be loosely coupled with the driver instance. Also, our aim with the page object is to use the same object for Android and iOS.

File name: HomePage.java

package com.lambdatest.appium.sample.pages;
 
import java.util.Map;
 
import com.google.common.collect.ImmutableMap;
import com.lambdatest.appium.sample.enums.Platform;
import io.appium.java_client.MobileBy;
import org.openqa.selenium.By;
 
public class HomePage {
   // 1.
   public Map<Platform, By> message () {
       return ImmutableMap.of (Platform.IOS, MobileBy.AccessibilityId ("Textbox"), Platform.ANDROID,
           By.id ("Textbox"));
   }
 
   // 2.
   public Map<Platform, By> notificationButton () {
       return ImmutableMap.of (Platform.IOS, MobileBy.AccessibilityId ("notification"), Platform.ANDROID,
           By.id ("notification"));
   }
 
   // 3.
   public Map<Platform, By> proverbialNotification () {
       return ImmutableMap.of (Platform.IOS, MobileBy.iOSNsPredicateString ("label BEGINSWITH "PROVERBIAL""),
           Platform.ANDROID, By.id ("android:id/title"));
   }
 
   // 4.
   public Map<Platform, By> textButton () {
       return ImmutableMap.of (Platform.IOS,
           MobileBy.iOSNsPredicateString ("label == "Text" AND type == "XCUIElementTypeButton""), Platform.ANDROID,
           By.id ("Text"));
   }
}

In this class, we:

• Created a message method representing the message element on the application home page, which will display text when the text button is pressed. This method will provide locators for both Android and iOS.
• Created a notificationButton method representing the notification button element on the application, which will send a native notification message on the notification panel. This method will provide locators for both Android and iOS.
• Created a proverbialNotification method representing the actual notification element, which is displayed on the notification panel after the user presses the notification button in the application. This method will provide locators for both Android and iOS.
• Created a textButton method representing the test button element on the application, which will show proverbial text on the message element. This method will provide locators for both Android and iOS.
• In the case of iOS, we composed the locator such that it will make sure we are interacting with the correct element. We combined attributes we found while inspecting the element on the inspector and created a predictable string query, where we will check for the label to be “Text” and the class type of the element to be a button.

Base test class

Once we have the page object ready, the next step is writing the tests. Again, we will have two test classes, one for Android and one for iOS. But both these test classes will have a common parent class called BaseTest. Let’s see what this class looks like.

package com.lambdatest.appium.sample;
 
import static java.text.MessageFormat.format;
 
import java.io.File;
import java.net.MalformedURLException;
import java.net.URL;
 
import com.lambdatest.appium.sample.enums.Environment;
import com.lambdatest.appium.sample.utils.Swipe;
import io.appium.java_client.AppiumDriver;
import io.appium.java_client.MobileElement;
import io.appium.java_client.remote.AndroidMobileCapabilityType;
import io.appium.java_client.remote.AutomationName;
import io.appium.java_client.remote.MobileCapabilityType;
import io.appium.java_client.service.local.AppiumDriverLocalService;
import io.appium.java_client.service.local.AppiumServiceBuilder;
import io.appium.java_client.service.local.flags.GeneralServerFlag;
import org.openqa.selenium.Capabilities;
import org.openqa.selenium.remote.CapabilityType;
import org.openqa.selenium.remote.DesiredCapabilities;
import org.openqa.selenium.support.ui.WebDriverWait;
import org.testng.ITestContext;
import org.testng.annotations.AfterTest;
 
// 1.
public class BaseTest<D extends AppiumDriver<MobileElement>> {
   // 2.
   protected static final String LT_KEY  = System.getenv ("LT_ACCESS_KEY");
   protected static final String LT_USER = System.getenv ("LT_USERNAME");
 
   // 3.
   protected D                        driver;
   protected AppiumDriverLocalService service;
   protected Swipe<D>                 swipe;
   protected WebDriverWait            wait;
 
   // 4.
   @AfterTest (alwaysRun = true)
   public void tearDown (final ITestContext context) {
       if (Environment.valueOf (context.getCurrentXmlTest ()
           .getParameter ("environment")) == Environment.CLOUD) {
           final var status = (context.getFailedTests ()
               .size () > 0) ? "failed" : "passed";
           this.driver.executeScript (format ("lambda-status={0}", status));
       }
       this.driver.quit ();
       if (this.service != null && this.service.isRunning ()) {
           this.service.stop ();
       }
   }
 
   // 5.
   protected Capabilities getOptions (final Environment environment, final String platform, final String deviceName,
       final String version, final String appKey) {
       final var app = environment == Environment.CLOUD
                       ? System.getenv (appKey)
                       : System.getProperty ("user.dir") + appKey;
       final DesiredCapabilities capabilities = new DesiredCapabilities ();
       capabilities.setCapability (CapabilityType.PLATFORM_NAME, platform);
       capabilities.setCapability (MobileCapabilityType.PLATFORM_VERSION, version);
       capabilities.setCapability (MobileCapabilityType.DEVICE_NAME, deviceName);
       capabilities.setCapability (MobileCapabilityType.APP, app);
       if (environment == Environment.CLOUD) {
           setCapabilitiesForCloud (capabilities, platform);
       } else {
           if (platform.equalsIgnoreCase ("Android")) {
               setCapabilitiesForLocalAndroid (capabilities, deviceName);
           }
       }
       return capabilities;
   }
 
   // 6.
   protected URL getUrl (final Environment environment) throws MalformedURLException {
       if (environment == Environment.CLOUD) {
           return new URL (format ("https://{0}:{1}@mobile-hub.lambdatest.com/wd/hub", LT_USER, LT_KEY));
       }
       if (this.service != null && this.service.isRunning ()) {
           return this.service.getUrl ();
       }
       return new URL ("http://localhost:4723/wd/hub");
   }
 
   // 7.
   protected void startServer (final Environment environment, final boolean isAutomatic) {
       if (!isAutomatic || environment == Environment.CLOUD) {
           return;
       }
       final AppiumServiceBuilder builder = new AppiumServiceBuilder ();
       builder.withIPAddress ("127.0.0.1")
           .usingPort (4723)
           .withAppiumJS (
               new File ("/path/to/.nvm/versions/node/v16.15.0/lib/node_modules/appium/build/lib/main.js"))
           .withLogFile (new File (System.getProperty ("user.dir") + "/logs/appium.log"))
           .withArgument (GeneralServerFlag.LOG_LEVEL, "info")
           .withArgument (GeneralServerFlag.SESSION_OVERRIDE);
       this.service = AppiumDriverLocalService.buildService (builder);
       this.service.start ();
   }
 
   private void setCapabilitiesForCloud (final DesiredCapabilities capabilities, final Object platform) {
	   capabilities.setCapability ("project", "LambdaTest project");
       capabilities.setCapability ("build", format ("TestNG {0} Sample Build", platform));
       capabilities.setCapability ("name", format ("{0} Test Case", platform));
       capabilities.setCapability ("console", true);
       capabilities.setCapability ("network", true);
       capabilities.setCapability ("visual", true);
       capabilities.setCapability ("video", true);
       capabilities.setCapability ("terminal", true);
       capabilities.setCapability ("devicelog", true);
       capabilities.setCapability ("isRealMobile", true);
   }
 
   private void setCapabilitiesForLocalAndroid (final DesiredCapabilities capabilities, final String deviceName) {
       capabilities.setCapability (AndroidMobileCapabilityType.AVD, deviceName);
       capabilities.setCapability (MobileCapabilityType.AUTOMATION_NAME, AutomationName.ANDROID_UIAUTOMATOR2);
   }
}

Let’s understand this class. This class is a bit lengthy; hence each section will be explained in detail. Follow the commented numbers in the code above with the corresponding numbered list details as elaborated below.

• We have a generic base test class with a generic type D, which extends AppiumDriver having a generic type of MobileElement. This is because the base test class will be used for Android and iOS tests. Hence the type D can be either AndroidDriver or IOSDriver

• Now we will get the credentials for TestMu AI, a cloud-based device lab provider. In case we want to run our tests on the cloud. We will look into how to run the test on the cloud with the help of TestMu AI later in this blog on Appium with TestNG.
• Next, we have instance fields that save different instances, which will help us in automation. Also, note that all these fields are marked protected, which makes all these fields accessible to both Android and iOS tests.
• Now, we have a teardown method that will help mark the test as pass or fail on TestMu AI if we run on the cloud. Later we will quit the driver instance. If we are running the test locally, we need to close the Appium service.
• Here, we will create and set the capabilities depending on where we want to run the tests, whether locally or on the cloud. Also, some capabilities are specific to local Android emulators, which we have handled.
• Get URL method will get the server URL on which our test will run based on the environment. For example, if we run on the cloud, we will get a cloud-specific URL. If we run on the server where our test starts, we will get that server URL. Otherwise, if we have a server already running on port 4723 or any other available port number, we will get that URL. This method will be used in the individual test class for both Android and iOS.
• The start server method will be used to start the Appium server programmatically by providing some server arguments, and this method will be called from our test. This method will not perform any action if we run on the cloud or have an Appium server already running externally.

Android test

In this section of this tutorial on Appium with TestNG, we will create a new class for the Android test where we will write two test cases as described earlier. First, let’s see how this test looks.

package com.lambdatest.appium.sample.android;
 
import static com.lambdatest.appium.sample.enums.Platform.ANDROID;
import static org.testng.Assert.assertEquals;
 
import java.net.MalformedURLException;
 
import com.lambdatest.appium.sample.BaseTest;
import com.lambdatest.appium.sample.enums.Environment;
import com.lambdatest.appium.sample.enums.Platform;
import com.lambdatest.appium.sample.pages.HomePage;
import com.lambdatest.appium.sample.utils.Swipe;
import io.appium.java_client.MobileElement;
import io.appium.java_client.Setting;
import io.appium.java_client.android.AndroidDriver;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;
import org.testng.annotations.BeforeTest;
import org.testng.annotations.Parameters;
import org.testng.annotations.Test;
 
// 1.
public class AndroidTest extends BaseTest<AndroidDriver<MobileElement>> {
   private static final Platform PLATFORM = ANDROID;
   private              HomePage homePage;
 
   // 2.
   @Parameters ({ "environment", "deviceName", "version", "app", "isAutomatic" })
   @BeforeTest
   public void setupDriver (final Environment environment, final String deviceName, final String version,
       final String app, final boolean isAutomatic) throws MalformedURLException {
       this.homePage = new HomePage ();
       startServer (environment, isAutomatic);
       this.driver = new AndroidDriver<> (getUrl (environment),
           getOptions (environment, "Android", deviceName, version, app));
       this.driver.setSetting (Setting.IGNORE_UNIMPORTANT_VIEWS, true);
       this.wait = new WebDriverWait (this.driver, 10);
       this.swipe = new Swipe<> (this.driver);
   }
 
   // 3.
   @Test
   public void testNotifications () {
       this.wait.until (ExpectedConditions.elementToBeClickable (this.homePage.notificationButton ()
               .get (PLATFORM)))
           .click ();
       this.driver.openNotifications ();
       assertEquals (this.wait.until (ExpectedConditions.visibilityOfElementLocated (
               this.homePage.proverbialNotification ()
                   .get (PLATFORM)))
           .getText (), "Test Notification");
       this.driver.navigate ()
           .back ();
   }
 
   // 4.
   @Test
   public void testTextButton () {
       this.wait.until (ExpectedConditions.elementToBeClickable (this.homePage.textButton ()
               .get (PLATFORM)))
           .click ();
       assertEquals (this.wait.until (ExpectedConditions.visibilityOfElementLocated (this.homePage.message ()
               .get (PLATFORM)))
           .getText (), "Proverbial");
   }
}

In this test, we are:

• Extending our BaseTest class and specifying the generic type of the class as AndroidDriver.
• Next, we have the setupDriver method, which takes parameters from testng.xml, which decides:

  a. In which environment will we be running our tests, on cloud or local.

  b. The name of the device.

  c. The version of the platform

  d. App path, local file path in the case of local execution, or app URL if running on the cloud.

  e. If we run locally, the isAutomatic parameter will tell if we want to start the server internally in our test or already have a server running on our external terminal.

  f. We are also updating the Appium setting to set IGNORE_UNIMPORTANT_VIEWS which will reduce unnecessary elements from the overall elements hierarchy tree.

• testNotifications test method will test our first test scenario where the user clicks on the notification button and sees a notification pop-up on the panel. We will also assert the notification text to ensure our test passes. Here we use the HomePage class to get the platform-specific locators.
• testTextButton test method will verify if the Proverbial text is displayed when the user clicks on the text button. We also use the HomePage class to get the platform-specific locators.

iOS test

Similar to the Android test, we have another class for the iOS test that also uses the same page object class used in the Android test. Let’s see what this class looks like.

package com.lambdatest.appium.sample.ios;
 
import static com.lambdatest.appium.sample.enums.Platform.IOS;
import static org.openqa.selenium.support.ui.ExpectedConditions.elementToBeClickable;
import static org.openqa.selenium.support.ui.ExpectedConditions.visibilityOfElementLocated;
 
import java.net.MalformedURLException;
 
import com.lambdatest.appium.sample.BaseTest;
import com.lambdatest.appium.sample.enums.Environment;
import com.lambdatest.appium.sample.enums.Platform;
import com.lambdatest.appium.sample.pages.HomePage;
import com.lambdatest.appium.sample.utils.Swipe;
import io.appium.java_client.MobileElement;
import io.appium.java_client.ios.IOSDriver;
import org.openqa.selenium.support.ui.WebDriverWait;
import org.testng.Assert;
import org.testng.annotations.BeforeTest;
import org.testng.annotations.Parameters;
import org.testng.annotations.Test;
 
// 1.
public class IOSTest extends BaseTest<IOSDriver<MobileElement>> {
   private static final Platform PLATFORM = IOS;
   private              HomePage homePage;
 
   // 2.
   @Parameters ({ "environment", "deviceName", "version", "app" })
   @BeforeTest
   public void setupDriver (final Environment environment, final String deviceName, final String version,
       final String app) throws MalformedURLException {
       this.homePage = new HomePage ();
       this.driver = new IOSDriver<> (getUrl (environment), getOptions (environment, "iOS", deviceName, version, app));
       this.wait = new WebDriverWait (this.driver, 10);
       this.swipe = new Swipe<> (this.driver);
   }
 
   // 3.
   @Test
   public void testNotifications () {
       this.wait.until (elementToBeClickable (this.homePage.notificationButton ()
               .get (PLATFORM)))
           .click ();
       this.swipe.down ();
       Assert.assertTrue (this.wait.until (visibilityOfElementLocated (this.homePage.proverbialNotification ()
               .get (PLATFORM)))
           .getText ()
           .contains ("Test Notification, Please enjoy this notification"));
       this.swipe.up ();
   }
 
   // 4.
   @Test
   public void testTextButton () {
       this.wait.until (elementToBeClickable (this.homePage.textButton ()
               .get (PLATFORM)))
           .click ();
       Assert.assertEquals (this.wait.until (visibilityOfElementLocated (this.homePage.message ()
               .get (PLATFORM)))
           .getText (), "Proverbial");
   }
}

In this test, we are,

• Extending our BaseTest class and specifying the generic type of the class as IOSDriver.
• Next, we have the setupDriver method, which takes parameters from testng.xml, which decides:
• testNotifications test method is almost identical, except that the openNotification method does not work here. Instead, we will use the Swipe util class to swipe down and open the notification panel. After verification, we will swipe up to close the notification panel.
• testTextButton test method is the same as the Android test.

In the next section of this Appium with TestNG tutorial, we will create a testng.xml file to execute the tests.

TestNG XML file

We now have all the test classes in place. Now it’s time to execute the tests for which we will create a testng.xml file in the project’s root folder. Let’s see how this file content will look.

• We declared the test suite for our tests.
• The first test is for iOS running on the TestMu AI cloud server.
• The second test is for Android running on the TestMu AI cloud server.
• The last test is for Android running locally where the Appium server will be started from our tests automatically and later the same will be closed once the test run completes.

Checking Execution reports

To check the tests that were executed using Appium with TestNG on the TestMu AI cloud server:

• Navigate on their dashboard to Real Device -> App Automation from the left navigation panel. You will see a screen similar to the following.
• When you click on any test sessions, a screen similar to the following will be displayed.

Here you can see the recorded video, all the event logs, device logs, network logs, etc.

Run the tests

Since we have a couple of tests running on TestMu AI, we must first save our TestMu AI credentials in the environment variables LT_USERNAME having your username and LT_ACCESS_KEY having your access key.

• To run the tests, you can directly right-click in your IDE on the testng.xml file and click Run.
• Another option is to run the test from your terminal by executing the following command.

> mvn clean install

This command will execute our testng.xml file because we have configured the Maven surefire plugin in our pom.xml earlier.

How to upload an app to the cloud?

In this Appium with TestNG tutorial, we have already seen some tests run on the TestMu AI cloud server. But to run the test successfully, we must first upload our Android / iOS application on the TestMu AI cloud server. We must upload the .apk file for Android and the .ipa file for iOS. While uploading, you will require your user name and access key.

Following are the ways of uploading the application.

Upload using the cUrl command

One way is to execute the following cURL command on your terminal window on Mac OS and Linux.

For Android:

curl -u "<your-user-name>:<your-access-key>" --location --request POST 'https://manual-api.lambdatest.com/app/upload/realDevice' --form 'name="Android_App"' --form 'appFile=@"src/test/resources/apps/proverbial_android.apk"'

For iOS:

curl -u "<your-user-name>:<your-access-key>" -X POST "https://manual-api.lambdatest.com/app/upload/realDevice" -F "appFile=@"your/ios/app.ipa""

In any of the above commands, you will get a JSON response where you can use app_url as your App capability. It will be in the format: lt://.

Upload from the TestMu AI dashboard

On the TestMu AI Dashboard, navigate to Real Device -> App Automation and click on the App Upload button towards the right of the screen.

After you have uploaded the file, you will get app_url on the screen as shown below:

Conclusion

In this extensive blog on automated app testing using Appium with TestNG, we learned many things. We learned how to set up our machine to automate mobile applications for Android and iOS and inspect elements on a local emulator and cloud devices.

We also learned about the different locator strategies, creating a single page object for Android and iOS, and leveraging Appium with TestNG to run our tests locally and on the cloud using test parameters. Finally, we configured the pom.xml file to run the tests using Maven commands.

Don’t forget to share your feedback on this Appium with TestNG tutorial. Also, share it with your network if you like it. If you are preparing for an interview you can learn more through TestNG interview questions.

a. In which environment will we be running our tests, on cloud or local. b. The name of the device. c. The version of the platform. d. App path, local file path in the case of local execution, or app URL if running on the cloud.

TestNG XML file

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "https://testng.org/testng-1.0.dtd">
<!-- 1. -->
<suite name="Mobile Suite" verbose="2">
   <!-- 2. -->
   <test name="Test iOS App on LambdaTest">
       <parameter name="environment" value="CLOUD"/>
       <parameter name="deviceName" value="iPhone 13 Pro"/>
       <parameter name="version" value="15"/>
       <parameter name="app" value="LT_APP_IOS"/>
       <parameter name="isAutomatic" value="false"/>
       <classes>
           <class name="com.lambdatest.appium.sample.ios.IOSTest"/>
       </classes>
   </test>
   <!-- 3. -->
   <test name="Test Android App on LambdaTest">
       <parameter name="environment" value="CLOUD"/>
       <parameter name="deviceName" value="Galaxy S10"/>
       <parameter name="version" value="10"/>
       <parameter name="app" value="LT_APP_ANDROID"/>
       <parameter name="isAutomatic" value="false"/>
       <classes>
           <class name="com.lambdatest.appium.sample.android.AndroidTest"/>
       </classes>
   </test>
   <!-- 4. -->
   <test name="Test Android App on Local">
       <parameter name="environment" value="LOCAL"/>
       <parameter name="deviceName" value="Pixel_5"/>
       <parameter name="version" value="10"/>
       <parameter name="app" value="/src/test/resources/apps/proverbial_android.apk"/>
       <parameter name="isAutomatic" value="true"/>
       <classes>
           <class name="com.lambdatest.appium.sample.android.AndroidTest"/>
       </classes>
   </test>
</suite>

Checking Execution reports

Run the tests

How to upload an app to the cloud?

Upload using the cUrl command

Upload from the TestMu AI dashboard