Appium Best Practices Every Developer Must Know

Appium is an exemplary open-source tool; It functions as an automation framework that is able to communicate between the user’s test script, the Appium Server, and the emulator or real device the script is being run on. 

This well-established framework is highly popular for testing mobile, web, and hybrid applications. Appium is cross-platform, meaning that users can use the same API and write test scripts that can be run on popular platforms like Android, iOS, and Windows. Additionally, the automation framework supports several different programming languages, such as Python, Ruby, C#, PHP, JavaScript, and Java. Appium was designed to be a mobile app testing counterpart to Selenium which is the most popular automation framework for web app testing. 

To utilize Appium to its maximum potential, it’s important to understand common pitfalls faced when starting out with the framework, as well as the intrinsic features of Appium. This guide will highlight a few best practices to help QAs enhance and optimize their Appium tests.

Best Practices: Testing with Appium

1. Parallelization

The purpose of Test automation is to make tests faster, less prone to error, and less labor-intensive. Thus, running test scripts on one device at a time seems a bit counterintuitive in that it’s time consuming and will take more resources. When implementing test automation, running a test script on as many devices as possible should always be the aim because it allows you to identify compatibility issues, get instant results, and rapidly iterate on any issues identified. 

Multithreading is a principal concept that is indispensable in writing efficient programs with fast execution times. To be more specific, multithreading allows the programmer to delegate tasks to many different threads, thus executing tasks concurrently and greatly reducing the run-time of the program. A good visual for this would be one man building a cabin. This one man would have to first cut down trees, then chop the wood, then begin to level the ground where the cabin is to be built, and so on. However, let’s now imagine that there are 20 men building that same cabin, each man could take on one task, and by working together, they could complete building the cabin at a much faster rate. 

One of the finest techniques to speed up the automated testing process is parallel testing; Parallelization is a technique that is frequently used in automation testing and is rather similar in concept to multithreading. Parallelization refers to the simultaneous execution of many automated test scripts against various environment and device configurations, either locally or as part of the developer’s CI/CD pipeline.

It is clear why parallelization is a popular approach when using automation testing. As a result of using parallelization, testing and development are more agile, resulting in more robust and high-quality test scripts. Additionally, by not running tests sequentially, a significant amount of time is saved without sacrificing the quality of the tests in any way. 

2. Use the Right Locators

QAs need to be skilled users of various Appium locator strategies in order to successfully test all desired components of an application. After all, if the scripts are unable to detect the required elements, then the entire automation process is rendered futile.

One of the most egregious mistakes made when writing automation test scripts is the overutilization of XPath locators. When writing a script, it is possible to use XPath in two different ways. 

1. Absolute XPath: This is the absolute path of the element and is very specific to it. It specifies the path from the root to the element in question. This probably sounds good; However, the con of using this locator strategy is that any change in the application can cause the absolute XPath of the element to change, which means the test script will need to be updated every time any change is made. This is highly tedious and impractical.
2. Relative XPath: This path doesn’t start from the root element and instead starts with the element desired; thereby if any changes are made to the application, the element can still be located.

So out of the two options, if XPath must be used, relative XPath is always the better choice. However, XPath is not recommended for use in test scripts due to it being very slow at finding the element in question at execution. This performance cost also varies across different browsers, with test script execution generally being the slowest on Internet Explorer. The reason why this happens is that browsers use different rendering engines and rules, thereby leading to differences in execution time when running test scripts with XPath locators.

Accessibility IDs are a more efficient alternative to XPath selectors.  These locators are highly used in test scripts for Android and iOS applications and are much easier and faster to use when compared with XPath.

3.  Use Page Object Model

Over time there will generally be extensive updates and changes made to any application. With the evolution of the application, locators corresponding to specific elements are also updated and thus rendered defunct in previously written test scripts. This can be very tedious and introduce extensive rework for QAs. 

This issue can be easily resolved by employing Page Object Model design patterns for creating test scripts. In this instance, the tests communicate with the page’s UI using methods from the page object class. By using POM design patterns, only the code included within the page object has to be altered if the page’s UI changes; the tests themselves don’t need to be modified. As a result, the locators used in the test script and the test script itself are kept separate. This ensures that changes in locators won’t lead to extensive rewriting across all test scripts. 

The advantage is that only the code included within the page object needs to be updated if the user interface (UI) for the page changes. Therefore, all modifications to support the new UI may be found in one location.

4. Run Tests on Real Devices

The number of devices released keeps increasing exponentially every year. This problem, called device fragmentation, is one of the main objectives of every testing team when carrying out application testing. In order to not miss any potential customers, ensuring that the application is functional and reliable on several different device/OS/browser combinations is imperative.

There are two potential options when it is necessary to carry out tests across different devices:

1. Using Emulators and Simulators:  Although emulators/simulators are generally easier to set up and are considered to be more cost-effective, they are not the best choice to confirm the functionality of an application. Emulators don’t always operate and act as a real device might; therefore, running test scripts on them is no guarantee of functionality on the actual device in question.
2. Using Real Devices or Real Device Cloud: The main caveat when conducting tests on actual devices is that it might be time-consuming to configure the device and set up several pieces of software. Fortunately, there is a superior choice: utilizing a cloud-based platform.

It is advised to execute Appium tests on a real device cloud; With 3000+ actual device-browser combinations, the QA can comprehensively test the mobile application with BrowserStack App Automate and be assured of its functionality across thousands of real devices.

Test on Real Device Cloud

5. Use Wait

The functionality of any test script is dependent completely on whether or not it can accurately identify the application’s elements and automate different test cases as per the specifications provided by the software development team. If the correct elements can’t be located, then the test will result in a false negative.

A very common reason for a test to not locate an element accurately, other than the use of incorrect locators, is not using wait commands. If the application has not loaded completely or lags for some reason between pages, the script will be unable to use the locator to find the element. For such scenarios, it’s important to implement wait commands.

There are two main types of wait commands that can be utilized:

1. Explicit wait: The explicit wait command indicates to the Appium driver to wait until the element is found before proceeding to the next line of code.
2. Implicit wait: The implicit wait command indicates to the Appium driver to wait for a specific duration of time while repeatedly searching for the element in question until either the element is found or the time runs out. If a list of multiple elements is given to the command it will search the page until at least one element is found or the time specified runs out.

6. Use Appium Logs

The Appium Server has the ability to build a rich information log and reporting structure. Many consider Appium Logs to be intimidating. Upon running a test script, there’s a confusing stream of logs giving information about the test script in progress, but the details are often unclear and mystifying.

It is a good practice to learn to read and use Appium Logs. The logs are very informative and reveal details such as:

1. The logs often have stacktraces related to any errors which took place during test execution. These can often be a good starting point when debugging and identifying errors to be fixed in the application or test script.
2. The desired and default capabilities specified in the test are also visible in the logs. These capabilities can be used to understand and modify the behavior of the Appium server.
3. To keep the log lines brief, the Appium log, by default, doesn’t provide timestamps. However, if you start the Appium server with –log-timestamp, a timestamp will be appended to the beginning of each line. When attempting to identify the causes of slowness or potential bugs, this is really helpful since the lines with longer execution times can be easily identified.

Appium is an automation framework which helps testers identify bugs early in the development cycle and reduces manual testing efforts. In order to get the best out of this testing framework, one must put the best practices mentioned above to use. These practices offer guidance to make mobile automation testing more effective and reliable.

Talk to an Expert