Get best of the week

How much is Appium for the people

In this article, we will look at the Appium tool. This article is an introduction to the introduction of automated testing of mobile applications. It will show what difficulties you may have to face when using this tool.

Consider a small task using the example of a “calculator”, try to write automated tests to test it and ... Let's start from the very beginning :)

Content


  • What is Appium?
  • Necessary minimum.
  • Statement and solution of the problem.
  • Confluenced :)

What is Appium?


A few words about mobile testing. You can not have a computer, laptop at home, but we don’t perceive our life without mobile devices. Testing mobile applications takes a big niche in ... testing ... Mmmm ... butter is butter, but it is. This niche is quite complicated.

There are so many devices with their operating systems, with their own graphical interfaces, screen resolutions, etc. I think this list is endless. So, due to the huge variety of mobile devices, it would be nice to have automated tests for our applications in order to reduce the suffering of testers and not turn testing of one functionality on hundreds of devices into “real hell” (see image below).

image

There are many tools for writing autotests for mobile devices. To solve the tasks set before me, I chose Appium, since it is simultaneously suitable for Android and iOS and you can write self-tests using "everyone’s favorite" Java.

Appium is a free, open-source, cross-platform tool that helps automate applications for both Android and iOS. Appium takes the same approach as Selenium WebDriver, which receives JSON HTTP requests from clients and converts them depending on the platform on which it works.

image

Minimum required


So what do we need to work with Appium?

To create tests for Android, the following requirements are put forward:

  • Java (version> = 7)
  • Android SDK API (version> = 17)
  • Android Virtual Device (AVD) / real device
  • Intel Hardware Accelerated Execution Manager

In order for the Android device emulator to work at a speed close to the speed of the real device, you need to install Intel Hardware Accelerated Execution Manager. This will help reduce the time it takes to launch and debug the application.

For iOS:

  • Mac OS X (version> = 10.7)
  • Xcode (version> = 5.1)
  • Java (version> = 7)
  • Homebrew
  • NodeJS
  • npm

I also recommend installing appium-doctor in order to diagnose possible problems when installing and configuring the necessary components on both platforms.

image

Statement and solution of the problem


So, let's imagine that we need to write automated tests for a calculator application for Android devices. To do this, we need to download Appium from the official site and install it on our “machine”.

image

Launch Appium.

image

By default, Appium is ready to listen to localhost with port 4723. Here we will leave everything unchanged and start the server.

image

Now Appium is ready to process our requests.

Our future autotest must be run either on the emulator or on a real device. For the versatility of this article, consider the work of the test on the emulator. For this we need Android Studio. Download and install it yourself. Then open and go to Tools - AVD Manager.

image

image

image

image

image

image

Now open the terminal and run the adb devices command. She will show the list of attached devices.

image

We see that the list of devices is empty, because no emulator is running, no real device is connected to our “machine”.

Run all the emulators that we have. In my case, these are two emulators. Run the adb devices command again.

image

Now we have a non-empty list that contains the ID of our attached devices - emulators and devices, if any.

With the emulator sorted out, let's start writing code. As described above, in my tests I use Java.

First, create an instance of AndroidDriver. The constructor of this class expects two parameters to enter:

image

Desired capabilities - JSON object (a set of key-value pairs) sent by the client to the server.

Desired capabilities describe the features of the created session (name of the device / emulator, operating system (OS), OS version, launched application, etc.). Capabilities

example:

image

We describe our capabilities and create AndroidDriver.

image

deviceName is a required parameter, but for Android it is not checked. If we talk about iOS, then when specifying the name, you must use one of the reserved names (an example of such names is given in the comments on the code). The description of other parameters is given in the code (see image above), but we will focus on some of them.

udid is a unique identifier for the device. We can get this device identifier with the adb devices command.

image

appPackage is the name of the Java package of the Android application that we want to run.

appActivities is the name of the activities we open.

appPackage and appActivities can be obtained in various ways, but the simplest of them is to install the “APK Info” application from Google Play.

After opening this program, you will see a list of all installed applications. We are interested in Calculator. Select it from the list.

image

And here is all the information we need.

image

image

Filled them. Next, create an instance of AndroidDriver: register the Appium URL and pass the capabilities object as the second parameter.

image

This code will only run the calculator on the emulator. We need to learn how to somehow manage the elements of the calculator so that we can write a simple test. The principle is similar here as in Selenium Web Driver. We need to access the elements through any locators. Appium Inspector will help us to get them. Open Appium.

image

image

Now all our capabilities described in the code must be transferred to the Inspector, in the Desired Capabilities tab.

image

Starting Session.

image

The inspector translates what is displayed on the device. A little to the right is a tree of all the elements of the current Activity. To get the attributes of an element, you just need to select the element we need.

image

After selecting, all the attributes that are available for this element are displayed. In this case, it is not so important for us how to access the element: by ID or xPath. But in large and complex applications, it is better to use IDs, since xPath greatly slows down the passage of tests. Also, when testing hybrid applications, the ID will be one for Android and iOS, and xPath will be different. We learned how to get the necessary attributes. Now, by analogy with the Selenium Web Driver, we get the necessary elements in the code.

image

To get the item, I use the findElementById method. You can create an instance of the MobileElement class and work with it, or you can without creating one. Here we define the elements of the numbers 2, + and 3. In the end, I expect the result to be 5. In the end, the result is the following:

image

I put the test and work on creating the session into separate methods. Now I’ll try to demonstrate what we did.


Confluenced :)


image

In this article I showed how to get started quickly with Appium and what is needed for this. As you may have noticed, starting to write simple tests is not so difficult. Then you can fasten the report to the project, for example, Allure. But this is a completely different story :)

Perhaps you will have individual problems when installing various tools that are necessary to work with Appium. But all these problems are easily solved by Google search :)

The topic of testing for iOS is not disclosed, but I want to “say”, or rather write a few words about it.

In order to run the application through Appium on iOS, I spent a lot of time setting up the environment (xCode, Appium, developer certificates, etc.). It was necessary to open the Appium project through xCode, specify the developer certificates and other settings, assemble the project, and only then it turned out to execute the commands through the Appium on iOS devices. After each update of Appium, you must perform this procedure. Perhaps everything will turn out much easier for you, you should believe in it. So far I have not found another solution, maybe it is, but so far it suits me.

I want to note once again that it is better to use IDs when accessing elements than xPath. Even if the element does not contain an ID, then ask / force the developer to specify the ID. This will make your life easier and increase your test execution speed.

And yet, the more real devices you have, the more likely it is to find a bug before end users find it. In principle, you can create your own factory of devices. But it seems to me more advisable to look towards cloud solutions, for example, BrowserStack, SauceLabs and others.

That's all I wanted to say!

PS Project on GitHub

PPS A little bit of my group

Now that's all!

More articles:


All Articles