Using Page Object Model With Appium And Java

Using Page Object Model With Appium And Java

Page Object Model is undoubtedly one of the best routes to go if you want to create manageable and reusable tests, avoid unneeded code duplication, and make your testing life a lot simpler! Before heading into it, let’s understand what is Appium and Page Object Model.

Appium

             In order to simplify UI automation of multiple app platforms, including mobile (iOS, Android, Tizen), browser (Chrome, Firefox, Safari), desktop (MacOS, Windows), TV (Roku, tvOS, Android TV, Samsung), and more, Appium is an open-source project and ecosystem of related applications.

Appium is mostly used in the realm of software test automation to assist assess whether a given app's functionality is operating as intended. Unlike other forms of software testing, UI automation enables testers to create code that iteratively runs through user scenarios in an application's real user interface (UI), as closely as possible simulating real-world behavior while maximizing the speed, scale, and consistency advantages of automation.

Have a look at its official documentation to find out more about how Appium achieves this objective and the many elements needed.

Page Object Model

Within the test code, a Page Object simply represents these as objects. As a result, there is less redundant code, and if the user interface changes, the patch only needs to be implemented once.

Because it improves test maintenance and minimizes code duplication, the Page Object Design Pattern has gained popularity in test automation. An object-oriented class known as a page object acts as an interface for a page of your AUT. When the tests need to interact with the UI of that page, they use the methods of this page object class. The advantage is that only the code included within the page object needs to update if the user interface (UI) for the page changes.

This strategy suffers from two issues.

  • The test method and the AUT's locators (in this case, IDs) are integrated into a single method; there is no distinction between the two. The test itself must be modified if the UI of the AUT changes its IDs, layout, or how a login is entered and handled.
  • In all tests that required the use of this login page, the ID locators would be dispersed throughout various tests.

With Page Object Model V/s Without Page Object Model

Article content

The difference between using Appium with the Page Object Model (POM) and without POM lies in the organization and maintainability of your test automation code.

Using Appium without POM:

  • In this approach, the test automation code is generally written as a sequence of actions and assertions without any clear separation between the UI elements and the test logic.
  • Locating and interacting with UI elements is done inline within the test code.
  • If the UI elements change, the test code needs to be updated in multiple places, leading to code duplication and higher maintenance efforts.
  • The reusability of code is limited as there is no separate abstraction of UI elements and their actions.

Using Appium with POM:

  • The POM approach introduces a clear separation between the UI elements and the test logic.
  • UI elements are represented as objects in the form of page classes, where each class corresponds to a screen or page in the mobile app.
  • The UI elements and their locators are defined and maintained within the page class itself, making it easier to update when the app's UI changes.
  • Test methods interact with the UI elements through the page class, helping reduce code duplication and promote code reuse.
  • The POM approach leads to more modular and maintainable code, as changes in the UI can be managed within the corresponding page class without affecting the test code.

Assumptions

  • You have Appium and the necessary dependencies set up. 
  • You have the app's APK file or bundle ID (for Android) or the app's IPA file or bundle ID (for iOS). 
  • You are using Java for scripting.

Implementing Page Object Model in Appium

Article content

The Page Object Model (POM) is a popular design pattern for automating tests on mobile apps using Appium and Java. It helps to organize your code and make it more maintainable. Here's how you can implement the POM with Appium and Java for mobile app test automation:

  • Begin by creating a new Java project and adding the required dependencies, including the Appium Java client and any other libraries you might need.
  • Create a "page" class for each screen or page in your mobile app. This class should represent the elements and actions on that particular screen.
  • Use the PageFactory class from the Appium library to initialize the elements on your page class.
  • Define methods on your page class to interact with the elements on the screen, such as entering text, clicking buttons, or verifying text.
  • In your test case class, create an instance of the page class and call the methods to perform the desired actions on the screen.
  • Use assertions or other verification techniques to verify the expected results of your test.

Here's an example of how your code might look like:

 To configure the pom.xml file for using Appium with the appropriate drivers, you'll need to add the necessary dependencies and plugins. Here's an example of what the pom.xml file could look like:

<properties>         
<appium.version>7.3.0</appium.version>         <testng.version>7.8.0</testng.version>     
</properties> 
    
<dependencies> 
        
<dependency>             
<groupId>io.appium</groupId>             
<artifactId>java-client</artifactId>             <version>${appium.version}</version>         
</dependency>     
    
<dependency>             
<groupId>org.testng</groupId>             <artifactId>testng</artifactId>             <version>${testng.version}</version>         
</dependency>         

<!-- Other dependencies you might need (e.g., Selenium) -->     </dependencies> 
    
<build>         
<plugins>             
<!-- Maven Compiler Plugin -->             
<plugin>                 
<groupId>org.apache.maven.plugins</groupId>                 <artifactId>maven-compiler-plugin</artifactId>                 <version>3.8.1</version>                 
<configuration>                     
<source>1.8</source>                     
<target>1.8</target>                 
</configuration>             
</plugin>         
</plugins>     
</build>         

In this example, we have added the Appium Java Client dependency with version 7.5.1 to the dependencies section. You may also need to add other dependencies if your project requires them.

// LoginPage.java

public class LoginPage {   
  
@AndroidFindBy(id = "usernameField")     
private WebElement usernameField;  
   
@AndroidFindBy(id = "passwordField")     
private WebElement passwordField;   
  
@AndroidFindBy(id = "loginButton")     
private WebElement loginButton;     

public LoginPage() {         
PageFactory.initElements(new AppiumFieldDecorator(driver), this);   }   
  
public void enterUsername(String username) {         
usernameField.sendKeys(username);    
}  
   
public void enterPassword(String password) {        
passwordField.sendKeys(password);     
}  
   
public void clickLoginButton() {         
loginButton.click();     
} 

}        
// TestLogin.java

public class TestLogin {     

private LoginPage loginPage;   
  
@Test     
public void testLogin() 
{        
loginPage = new LoginPage();         loginPage.enterUsername("myusername");         loginPage.enterPassword("mypassword");         loginPage.clickLoginButton();         

// Add assertions or verifications here to validate the login functionality     
} 
}        

This is just a simple example, and you can extend it as needed for your specific mobile app. Remember to update the @AndroidFindBy annotations with the appropriate locators for your elements.

I hope this helps you get started with using the Page Object Model for mobile app test automation with Appium and Java. 

Thank you!!


Knoldus Inc | part of NashTech NashTech Learning Express

To view or add a comment, sign in

More articles by Aditya Kumar Singh

Others also viewed

Explore content categories