Chapter-13: Appium Tips and Tricks

Chapter-13: Appium Tips and Tricks

You’ve made it this far! By now you’re a full-fledged Appium ninja. It’s time to round out some of your new skills with additional tips and tricks.

Appium is a sophisticated and ever updating testing platform, and with a growing user base forming, you’re bound to see some cool tricks by monitoring discussion boards and blogs.

In this chapter, we’ll look at some practical tips that you can put into practice immediately to improve your test case authoring. Let’s get started!

  • 1) How to check whether an Android app is already installed or not?

    • There are scenarios in which you want to check out whether your Android app is already installed on the device or not, but why would you need that?

      A very simple (but common!) use case requires testing a part of the app that is only accessible to logged-in users. So every time you execute your test case, the first step would be to login which is a time consuming operation (from an execution perspective).

      We can skip the login if we’ve already logged in on the previous test execution, as it takes unnecessary time. We can do 2 things:

      1. Set the desiredcapabilities for “noReset” as true and “fullReset” as false. So if your app has already been installed, Appium neither uninstalls it nor clear the cache data. It will simply open the app every time, So login will take place only at once, when you open the app first time after installing it.
      2. To avoid reinstalling the app everytime, fire $ adb shell pm list packages on your terminal - it lists all the packages of installed apps. You can create test logic like if the app you want to automate is displayed on that list then you can skip the installation.

      Now the question is how would you fire this command within your programming language?

      In Java this is done using the ProcessBuilder class:

  • 2) How to enable mouse pointer location on Android at runtime ?

    • As we discussed in an earlier chapter, if there is no unique locator assigned to a UI element then the only option is to tap on a particular point. By enabling “pointer location” in developer options in Android we can get the x, y coordinates for any point.

      Moreover having the mouse pointer location helps so much in debugging, especially whenever you are dealing with swipe, touch and scroll functions in Appium.

      But what if you are dealing with remote devices(such as Kobiton or BrowserStack devices)?

      There are case in which you cannot access the remote device before executing the automation test cases. So you will need some way to enable the pointer location on that devices at run time.

      If you want to enable mouse pointer location using the terminal then fire command:

      $ adb shell settings put system pointer_location 1 [Use 0 for disable]

      In Java you can use this code:

      You can find this example on our github page: https://github.com/appiumbook/appiumbook/blob/master/Chapter13-Appium%20Tips%20and%20Tricks/src/test/java/testcases/AndroidADBCommands.java

      Figure-1: Android Point Location Enabled.

  • 3) How to capture Screenshots On Test Failure?

    • This is the most vital feature of Appium (and Selenium). Practically speaking, with automation you are not observing the execution of all test cases, so in case a failure occurs you won’t have the exact details of the failure. That’s why this feature comes in handy, because it will capture the screenshot whenever a failure occurs. And by looking at the screenshot sometimes you can quickly figure out the failure cause without taking a look at the error log.

      Note: Cloud device platforms like Kobiton offer the ability to automatically take not only screenshots of every action, but also record full video of your test sessions as well as detailed Appium and device logs.

      Below is the code you use to capture a screenshot:

      But we need to call this method only if test cases are failing or being skipped. Thus we need to check the status of the test case, and, as we are using the TestNG test framework, we can use its methods to check the status of the executing test case.

      This code example works for both iOS and Android. The code is implemented in the github repository BaseTest.java

  • 4) How to dismiss dialogs/alerts automatically ?

    • In mobile application notifications, popups and dialogs occur at random so in order to access the app we must handle that immediately as soon as they appear.

      Appium can handle the system dialogs/alerts in 2 ways:

      1. Manually: In this approach you have to find the locators of the allow/deny button of the element and then perform a click() action on it.
      2. Automatically: You can set the desired capabilities to auto accept or deny the alert/dialogs.
      Auto Accept the Alerts:

      Auto Dismiss the Alerts:

      In some scenarios when you are not able to get the dialog elements, you can leverage the Appium image comparison feature and find the element by image. We will look more into that feature in a subsequent chapter.

  • 5) How to handle notifications in Android?

    • Push notification assertion is a common exercise you need to be familiar with because many apps send a push notification while you are accessing the app.

      Appium provides a super easy way to open notifications - you just have to call the openNotifications() method.

      You can get the title of the notification using android:id/title and the content of the notification using android:id/text locators.

      For example:

      See AndroidTricks.java on our github repository.

      NOTE: driver.openNotifications() method only applies to AndroidDriver object. It is not available for IOSDriver.

  • 6) How to make test cases fail fast in order to quickly get an error message?

    • As strange as the name of this trick may sound, there are cases when you want to fail your test cases faster in order to get the error message to fix the test case.

      Using the newCommandTimeout desired capability you can specify the time in seconds for which Appium will wait for a new command from the client before assuming the client quit and ending the session.

      If you are executing the test cases locally you want them to fail quickly, so ideally you should wait for 10 to 20 seconds (depends on app) because during that time app will load all the resources. With remote devices, due to network latency and other reasons, apps on remote device may take more time to load the resources so for remote execution that time period should be closer to 60 seconds.

  • 7) How to handle the hide_keyboard() method?

    • Essentially, it’s as simple as calling hide_keyboard(). However, the hide_keyboard() method works differently on iOS and Android because the internal architecture of the soft keyboard on both platforms is not the same. It also depends on the physical device model and its operating system version. Therefore, standard practice is you should put the hide_keyboard() method in a try/catch block.

  • 8) How can you write test cases faster?

    • Unfortunately QA engineers are facing increasing pressure to deliver more, faster. In this Agile world, requirements and releases are changing faster than ever which means your Application Under Test is constantly changing.

      And with continuous deployment, there is a good chance your test case becomes obsolete before that glorious bug is discovered.

      The following tips will help you to develop test cases at a faster pace:

      • Use a local appium server and local device: Appium performs the best with a locally installed appium server and having the script execute on a physically connected real device. Save the cloud device testing for increased coverage testing and for full regression tests.
      • Extract all the UI element locators of the application at first go: You can simply navigate the whole app with Appium Inspector (or another tool) and note down all relevant Ids, text or class name for the UI elements. The objective here is to save time by getting all the element locators at first go, so you won’t have to find the locator of element when you are in the middle of writing your test case.
      • Communicate with developers and assign a valid, and unique, ID to UI elements: This is the most common scenario where no unique id, class name or text is assigned to a UI element so you have to use the XPath locator which might contain the index. But relying on XPath indexes is brutal especially when your application under test is under development, because minor changes in the UI can change the index of all elements. As a point of cooperation between QA and Development, a naming convention or best practice should exist the ensure unique IDs are used. Whenever you find yourself using an XPath, stop to ask why and see if you can have the dev team provide unique IDs instead.
  • 10) How to handle to mobile data, wifi and airplane mode in Android?

    • In order to automate various connectivities such as mobile data, wifi and airplane mode, Appium provides a ConnectionState class for setting and getting the network connection for a connected android device/emulator.

      For example if you want to turn on only wifi(Not mobile data and airplane mode), you can use this command:

      You can see the example on: Example link

      This API works based on the android device OS versions so please go through the official appium documentation in order to get more information.

      NOTE: The above mentioned APIs are not available for iOS.

  • 11) How to switch context?

    • There are two main types of context in Appium:

      1. WEBVIEW
      2. NATIVE

      While we are working with a native application, the context will be NATIVE. And when webview is being used on some screen it will have the WEBVIEW context. Sometimes you actually have both in a single application. You might have experienced the webview when you are dealing with payments in an application- generally the payments page is integrated the in form of webview (being provided by the payment gateway). So in that case you need to change the application context from NATIVE to WEBVIEW in order to get control of WEBVIEW elements.

      Using the below code you can get the current context of your app:

      In a similar way you can get the all contexts available to automate using:

      And using this code you can change the context to WEBVIEW:

      You can use the this method in order to change the context to WEBVIEW if it is found:

  • 12) How can you minimize and reopen the app again?

    • There are some scenarios where you need to minimize the application and need to re open it without killing the current session. Using the runAppInBackground(Duration time) method you can hide your application for a particular duration.

      For example if you want to minimize application for 5 seconds then you might use:

  • 13) How to start Appium Server programmatically?

    • In all our examples up until now we have presumed that you have started the appium server explicitly using the command line or using the Appium Desktop application.

      Now when you are thinking to integrate appium UI test cases with Jenkins (or generally within in a CI/CD pipeline) you have two options to start the Jenkins server:

      1. Specify the command($appium&) in the build section of Jenkins to run the appium server.
      2. Start the Appium server by writing the code in the test framework in such a way that the server starts before the tests execute, and quits automatically at the end of the execution.

      Here, option 1 is not advisable because if a test failure occurs then the Appium server will be continuously running and occupying memory of the physical server. While in option 2 we have server quit code written at the end of execution, so even if failure occurs it will quit the Appium server and free the space in memory.

      You can start the server using 2 classes:

      1. AppiumDriverLocalService: It is simply used to start and stop the appium server.
      2. AppiumServiceBuilder: This class is used to build the appium service, here you can specify the appium server url, port, desired capabilities and some other parameters. This is recommended if you really want to customize the server details.

      So let’s look into the example of both classes:

      AppiumDriverLocalService:

      In the above example Appium will start the server using default url and port.

      You can find this example at: AppiumDriverLocalServiceTest.java

      AppiumServiceBuilder:

      Here as you can see appium will use Port: 4729, URL: 127.0.0.1 with some Desired Capabilities and flags.

      You can find this code at: AppiumServiceBuilderTest.java

Conclusion

Hopefully you found (or will find!) these tips and tricks useful as you progress your journey of being an Appium expert. The Appium community is constantly expanding and you’ll find tremendous tips and tricks shared by other developers and testers. Keep reading forums and blogs to keep your knowledge up to date.

Jonathan Lipps, the project lead of Appium, has created an amazing blog at https://appiumpro.com in which he has compiled some of the best practices and tricks to use Appium in an effective way. We strongly recommend you visit this blog and subscribe to the helpful mailing list to continue learning interesting things about Appium.

No Comments

Post A Comment