No comments yet

Appium Mobile Test Automation

As we all know that Appium is the most preferred test automation tool for mobile applications. It is the first choice of the testers because of its flexibility i.e. it is open source, it has the best supported and highly active community of experts, Appium works across different platforms and works well with different scripting languages. Even after gaining such popularity and having a strong community base, surprisingly, the users still make mistakes while running the mobile test automation with Appium.

Here are a few common mistakes that Appium users encounter while using Appium Mobile Test Automation Tool:

1.Unrestricted X Path Usage:

Over usage of X Path could be found in case of Selenium as well but when it comes to Appium world, it has more outrageous effects because X Path is a more dynamic way to unearth the elements. But the biggest stumbling block in this scenario is its huge performance cost due to which it becomes elusive an area. This is because Google and Apple do not provide XML or XPath related queries in a way we would need them to be. All of this hospitalizes an unmanageable cost finding elements using X Path. Undoubtedly, X Path is the most trusted method but there are several other better locator methods like ‘Accessibility IDs’ that can be used in this sitch.

2. Neglected usage of Accessibility IDs:

The accessibility ID locator strategy is formulated to read a unique identifier for a UI element. For both iOS and Android, getting an element by their accessibility ID is the best method. Most importantly, it is preferable because it is quicker. It should be noted that semantically accessible IDs are different than the Web IDs. However, the two shouldn’t be combined. In many cases, the accessibility IDs are used only for the purpose of testing even though they have a larger purpose. So, in order not to spoil the accessibility of the applications just for the sake of testing, the bigger purpose of the accessibility IDs should be known. If the accessible IDs are set up on the elements to make the apps testable, the app accessibility also increases, provided that the accessibility labels are sensible to the users using them. But the foremost criteria not to make automation efforts a failure is to make the application testable in the first place.

3. Not making a testable App:

Developing an app should be a forecasted move where in the developers, even before writing the first line of code, plan to develop an app keeping the automation in mind. This they can achieve by keeping in mind the hooks and the unique IDs for the elements in order to make the app more testable. This strategic approach would be a reason for a successful mobile app test automation. Apart from this, there should also be a concentration on the different testing scenarios in order to elude the chances of overlapping before even getting into Appium coding. An open discussion forum with the development teams to discuss the plotting of right accessibility IDs, labels or Unique IDs for the application’s elements would reduce many test automation reliability concerns.

4. Disregarding Application View States:

One of the challenge faced in Mobile Test Automation is not setting up the application. Most of the developers do not set up the application in order to access specific views and user states rapidly. To quote an example given by Jonathan Lipps,one of the key contributors to the Appium project.

A shopping cart functionality of the app might have ten different tests, and ninety percent of the tests might go through the same steps of logging in and searching items to be put in the cart which is a huge waste of time.

So, your team should be able to set up an app’s state and start the test in that apposite state, straightaway. This is highlighted in Appium scenario due to the fact that the mobile simulators and emulators are slow and take longer than usual to reach to the right position on the test.

5. Query for every element visibility:

Not querying for the visibility of every element is another way to speed up the run-time of the Appium test scripts. This leads to an additional load of calls and waiting time for Appium while in the every activity of retrieving an element. The lag can be reduced by only requesting the element attributes which are important in perspective of the test code.

6. Native Testing tools – Always better?

According to some developers, usage of the native testing tools is the best way to get unfailing mobile tests. For example- Espresso in case of Android and XCUITest in case of iOS. This is not good advice as neither of Google or Apple are going to release and new automation technology. When the question is of stability, the stability of code should be chosen rather than technology and in this scenario, Appium is the best choice!

As an exception, if the development team writes the tests and it’s most comfortable in mobile SDK language, using Google and Apple providers to build development environments. Also, when the constricted test-app or test code-app code integration is needed, then Appium might not be of much help. The utmost value is that Appium provides the WebDriver layer on top of the technology, which means the code can be written in any language and acts as a stable interface to that specific automation technology. Also, being a cross-platform tool, Appium allows to saves a lot of code and architecture in case of testing both iOS and Android devices.

7. Appium is slow:

Appium might be slower in some circumstances and also there are points in Appium codes where it does not seem efficient. Appium backs upon technologies that are slower than Appium and the curators of Appium have strategically chosen to utilize slower strategies for specific instances. For eg: Appium will certainly be slower if you are relying on XPath. The efficiency of the tool depends on how it is being used. Mostly, Appium is favored because of stability than the speed.

8. Not Using Appium Documentation:

The earlier Appium docs were not very user friendly. As a result, they weren’t used as much as they needed to be but the new Appium documents have been completely redesigned and reorganized. Information about the API reference to Appium, client libraries, supported drivers and Appium commands, code examples which was not provided before is all documented in the updated version. It deserves a revisit due to its newness and can be accessed at Appium.io.

9. Not creating reusable code

Repetitive or duplicate code can cause several issues for Appium mobile testing process. When the same code is repeated in several test scripts, any updates or modifications must be copied across all instances. This increases the chance of failures and complicates the debugging procedure. It also increases the maintenance cost for the organization.

Duplicate code makes identifying the primary reason for a test failure challenging. It can be difficult to pinpoint which occurrence of the code caused a test to fail if the same code is used repeatedly throughout several test scripts. This could increase the duration required for debugging the software and expand the market time.

Therefore, it’s crucial to use appropriate coding principles to prevent these issues. This includes creating simple reusable code, utilizing libraries and frameworks, and modifying code to remove redundancies.

10. Ignoring the Test-driven Deployment

Test-driven deployment is an Appium mobile test automation approach that stresses developing automated test cases before writing application code.

It lets the developer test all the application features before being deployed. This way, they can detect and resolve any bug in the early stage. This saves not only the organization’s time but also valuable resources.

Not just this, Test-driven deployment also helps developers in developing more reliable and enduring codes. By allowing them to understand the needs and provide a solution accordingly. Which lets them create more modular, maintainable, and error-free codes.

11. Choosing the right tool for API testing

APIs may have several endpoints, each with a unique set of parameters, methods, and authentication requirements. Writing and maintaining tests that accurately reflect the behavior of the API can be challenging due to this complexity.

Another difficulty is the requirement to simulate various scenarios and inputs. Testing for different response codes, error messages, and payloads might be part of this. To ensure the API can manage a high volume of queries, developers might also need to simulate load and stress testing.

Developers use a testing framework or library like RestAssured and Postman, which provides integrated support for API testing. These tools streamline and simplify the testing process by providing pre-build methods for common API testing scenarios, these tools streamline and simplifies the testing process. Alternatively, they can mimic various scenarios and inputs using mock data or a staging environment.

Developers can test their API in a safe setting before releasing it for production. Moreover, they can evaluate the API’s capacity by simulating heavy requests using load-testing tools like JMeter or LoadRunner.

12. Need to follow a good design pattern.

In Appium mobile test automation, the Page Object Model (POM) and the Page Automation Layer Model (PALM) are popular architectural patterns. Both techniques increase automated tests’ maintainability, scalability, and reusability.

POM is a design pattern that emphasizes the creation of reusable and modular code by isolating the application’s user interface from the test automation code, making it simpler to update tests when UI changes are made. POM builds an object repository that holds all the web elements and methods.
PALM is another design pattern that builds upon the principles of POM. But unlike POM, which focuses on UI elements, PALM emphasizes creating an abstraction layer between the test automation code and the application’s business logic. This approach distinguishes the test automation code from the underlying implementation. Thus making it easier to modify the test code without affecting the business logic.

No comments yet

Why Appium is The Best?

With Appium creating a buzz in enterprise mobility, mobility teams are still finding ways to successfully automate tests leveraging Appium. Appium being an open source tool is the perfect choice for automating native, mobile web and hybrid applications on their respective platforms.

Let us now see the major factors behind Appium being the best choice for mobile automation tool:

1. Use of standard API: Appium is widely popular because modification of codes or a recompilation of your app is not required as it uses the standard API in all the platforms. Appium makes it effortless to create your tests against iOS and Android platforms with same API. But, separate iOS and Android scripts are still needed as the UI elements vary on both the platforms.

2. Use any WebDriver compatible language: Appium gives the freedom from getting locked into a particular language or framework to write and run the tests. Any WebDriver compatible language like Perl with Selenium WebDriver API, Java, PHP, C#, Python, Ruby, Javascript with Node.js can be used for writing the tests.

3. Testing Framework of Choice: Appium gives flexibility to mobility teams to use testing framework of their choice. Earlier, tests could only be written through Javascript using the UI Automation of library for Apple or Java based tests could only be written through UI Automator of Google. Appium completely changed this scenario.

4. Cross-platform test automation: Having the capabilities to test on both Android and iOS devices makes it the best cross-platform mobile app test automation tool. In order to interact with Android and iOS with Selenium WebDriver, Appium uses the JSON wire protocol. Appium makes use of the libraries provided by Apple with the help of an application called Instruments to automate iOS apps. In newer versions of iOS after v9.3, the Instruments api has been deprecated and now use XCUITest framework.
The method is similar in Android also where Appium proxies the automation command to the UIAutomator test case running on the device. Android has a native UI automation framework called UIAutomator which supports running JUnit test cases from the command line directly into the device.

5. Open Source: Being an open source testing framework is one of the biggest advantages of Appium as it supports Simulators, Emulators, real devices, and of course, native, hybrid and web application testing of iOS and Android. Appium having a large and thriving open community makes it easier for new automation engineers to clarify their doubts.

You can instigate test scripts created from Appium libraries locally, on a session reserved by the Cloud, for any iOS or Android device. Appium integrates with continuous integration servers to ensure better results and drives GUI-related widgets and controls, allowing the same scripts to run for different software versions of various apps. Appium can automate native, web and hybrid mobile apps, and you can test on a real device, a simulator, or an emulator. It also supports Safari on iOS and Chrome Mozilla or any built-in ‘Browser’ app on Android.
There are many automation tools for mobile application testing. Testers usually choose Appium as the best mobile testing tool. Mobile automation testing tools comparison can be done on the basis of language support and continuous integration. The most common automation testing tools used for mobile application testing are Appium, Robotium, and Calabash. If you are looking for iOS app automation testing tools then Appium and Calabash can do the job for you.

Here is tabular representation for you to understand Appium’s compatibility with different features and tools.

Why mobile device cloud with built-in Appium support?

Teams who are getting started with Automation or are considering Appium as an option, must explore an alternative to go for a mobile device cloud with built-in Appium.

A mobile device cloud not only assists in managing and sharing devices, but also helps in streamlining automated testing and continuous delivery processes. A mobile device cloud with built-in Appium makes it easy for teams to get started with automation and scale up later. Furthermore, it will give additional cushion against any sort of roadblock that might occur while using an open-source platform for tests. Let’s have a look at some of the benefits of having a built-in Appium support on a mobile device cloud:

• Supports parallel testing on multiple devices
• Reduces the complexity of test frameworks
• Creation of appium scripts become easy
• Streamlines the CI/CD process

At pCloudy, we are dedicated towards helping enterprise mobility teams make the process of mobile development, testing and device sharing seamless and faster by integrating it with cutting edge tools like Appium. Read this blog to get a comprehensive analysis sheet to quickly choose which open-source test automation tool will be right for your automation testing.

Sign up on pCloudy and automate your tests using best open source automation tool for faster and better delivery of apps.

For more information check out this video:

No comments yet

Flutter has been creating waves in the app development space since its launch. The reason is simple, it solves the problem of creating two different codebases for a single app to run on Android and iOS devices. Some experts say that Flutter which was launched by Google is to counter React Native which is used by Facebook. Nevertheless, this is a much-needed relief for enterprises as Flutter will help them save a lot of their time and resources. So let’s first understand what is Flutter.

What is Flutter

Flutter is an opensource mobile UI framework that can create Android and iOS apps from a single codebase. The Flutter framework includes the Flutter engine, Dart platform, the Foundation library, and design-specific widgets. Flutter apps are written in Dart programming language and runs on dart virtual machine.

How to Create a Flutter App

Before we start the process of app development it is important to know that there are two types of widgets, stateless and stateful. A stateless widget describes part of the UI by building a structure of other widgets that describe the UI more definitive. Stateful widgets are the widgets that can change their state multiple times and can be redrawn on to the screen any number of times while the app is in action.
 
To create a Flutter app you need to install Flutter SDK and other tools required to support the framework. We will create the app in Intelli J IDE and for that, you need to install two plugins. The first one is Dart and the second plugin is Flutter. You can install the plugins by clicking on File in the menu bar of the IDE and then click on Settings.
 

Then you need to create a new project and you will get a basic code layout to start with your app development. In the first line, we have the main method where we will enable the flutter driver extension and there is a run app method with MyApp class instance, to run the app.
 

In this sample code, we have used the title as the stateless widget and we have set the title as the key and for the home screen, we are using one more instance which is MyStatefulWidget(). So in this class, we have a small piece of code, where we have set values for elements like appBar, background color, and in the body, we have placed a floating action button for a counter.
 

After adding the code you can run the program and you will be able to see the changed state of the counter with every click on the action button.
 

Appium Flutter Driver

Appium Flutter driver is a test automation tool for flutter apps on multiple platforms. It is a part of the Appium mobile test automation tool. But how does the Appium Flutter driver work? It uses webSocket communication to carry WDIO script to instantiate the flutter driver and the request will be sent to the particular application. Then the AUT will send the response to the script through the Appium Flutter driver.

You can also build Appium in your machine through the source code. Once you have cloned the source code, run npm install then npm run built and type a command node to start the Appium server. You can download the package from GitHub. The package contains Appium Flutter Driver and Appium Flutter Finder. You can clone the sample project to get the WDIO code.
 

In the terminal, you can see that to automate flutter application we have used Flutter as an automation name for both Android and iOS apps. You can see that port is 4723 and in the capabilities, we have mentioned osSpecificOps, automation name: ‘Flutter’. We have mentioned the app path at the top with the device name and platform name and we created an object.
 

Appium==OS environment is ‘android’ which will pick all the information and specify in the capabilities and it will pass a post request to the server.
 
Now here we are trying to find the element using CounterTestFinder and a ButtonFinder to click on the button. In the next line, we have created a driver using a remote method.
 
Then we have switched the Native App context to Flutter. You can switch this if you are using the Flutter app. Once the app is launched, we are validating that the counter text finder has value as zero by calling Flutter APIs internally. So here we are using two actions, one is clicking and the other is touch.
 

The button is to be clicked two times and thus we have used strictEqual function. In the last line of code, we are deleting the session.
 
Now to run the test we need to pass the environment variable to connect the device.
 

Then we will check if our Appium server is running.
 

Then once you run the code you will be able to see the actions performed on the device and the counter will change to two.
 

This is how you can automate your Android and iOS app testing using Appium Flutter driver. Although there are many benefits of using Flutter, there are some limitations as well. The first thing is that you need to learn Dart language to develop and automate the Flutter app.
 
Suppose you need to run automated tests on multiple devices, then you will have to fire multiple commands in the terminal. Appium flutter driver depends on Flutter Driver APIs and as it’s still not matured enough, some actions cannot be performed.

No comments yet

[xyz-ihs snippet=”quickLinks-Appium”]
 
In our previous chapter on Android, we learned about UI Automator Viewer, Which is available on Android SDK, to get the properties of the application object. In the case of iOS, Appium itself provides an Inspector which helps users to locate those elements in the application.
 
First, open the simulator by clicking on the dock option.
 

Now in the Device/Simulators window, select the simulator. Open the Appium Desktop and keep the simulator side by side.
 

Once the inspector is started, select any of the objects on the screen. It will show you the complete hierarchy and properties of that object.
 

At the top of the window, you can see the Record button which is used to record all the actions taken and record the script.
 

To select any object, click on the Select Element button and then you can use Tap button to click on an object, Send Keys to enter text and clear to undo the action.
 

As soon as you perform an action on an object, it is recorded in the form of a script.
 

Once you are done with the recording you can copy the script and paste in eclipse editor.
 

In the next blog, we will learn how to write the first appium script for iOS.
 
Related Articles:

No comments yet

In the last blog in this series we learned how to start the Appium server and launch app from the code. In this blog we will understand how to setup Appium on a Mac machine.

Pre-requisite

• Mac Book
• Xcode
• Simulator or real device
• Appium
• Eclipse
• Java

The first step is to install Xcode in the Mac Book. To do that, open app store and search for Xcode and click on the Get button to download Xcode.

Then click on the Install App option. This will install Xcode on your Mac machine. Now click on the Agree button if you agree with the terms and conditions and it will start installing components.

Once the Xcode is installed, you need to select “Create a new Xcode project” and you will be redirected to the template selection option.

You may select any of the templates or leave default settings as they are. Click on the next button to navigate to the next screen.

Now you will be asked to provide a product name and other product-related settings.

Enter the required details and click on the next button. In the last seen of product settings, you will be asked to give the location in which to save your project.
Select the location anywhere as per your requirements and click on the create button.

Once the project is loaded go to the Product menu option and click on the Run option.

Once you click on the run option, it will launch iOS simulator.

Now right click on the simulator icon on the doc panel and select the keep in doc panel. In this way, you don’t need to start Xcode to launch the simulator. Thus you don’t need to open the Xcode project each time to launch iPhone simulator. If you want to see the list of simulators, got to the Window menu and select the Devices option. You will get a list of all the simulators available with this version of Xcode.

Installing JDK and setting the path

Download JDK for Mac OS and once the file is downloaded, double click on the file and install Java.

Now you need to set the Java installation path in your environment variable. Open a terminal and write “open.bash_profile”.

If “.bash_profile” does not exist then execute the command “touch~/.bash_profile”. This will create the file. So when you execute the command, it opens the “.bash_profile” file.

Copy the path to JDK home, write export JAVA_Home= and then save this file. Open command prompt and execute the java – version command. Open Appium.io and click on Download Appium button.

Now download the latest .dmg file and once downloaded, double click on the .dmg file.

It will open a new window where you need to drag and drop Appium into the application folder.

Search for Appium and double click on the Appium icon. This will launch the Appium server on your Mac machine.

To Launch Appium on a simulator click on the Start Server button.

Now click on the Start Inspector Session button in the Appium server.

Once you select pCloudy as the cloud provider from the list you can click on Done.

Then you need to enter the Hostname, User name, API Key, Desired Capabilities and then click on Start Session.

Your simulator is now connected.

Now you know how to setup Appium on Mac and in the previous blogs in this series we explained how to write the test script and start Appium server. In the next blog we will learn how to use Appium inspector to identify elements in an app.

Related Articles:

• How to use Appium Inspector for Test Automation
• Basics of Appium Mobile Testing
• How To Achieve Scalability,Quality And Speed With Appium
• Inspecting Element on pCloudy Devices Using Appium Desktop
• Starting Appium Server and launching the app from code

No comments yet

In the previous blog in this series, we learned how to write the first Appium script for Android devices. Now in this blog, we will understand how to start the Appium server.

The code structure is segregated into three parts, the first part of the code starts the Appium server, the second part stops the Appium server.

The third part is the main method which is necessary to execute the class and from this main method, all the above method are called.

Starting Appium from code requires a path of two files which are kept inside the Appium folder.

• node.exe
• js

Starting Appium Server

In the code highlighted in red, we have called process class which is a Java class and declared it static.

We then created a start server variable and pass the path to node.exe and main.js, highlighted in yellow. In the code highlighted in green, we added both paths into the same variable with spaces and created a method called startAppiumServer() which takes care of the Appium server startup process. Next step is to create an object of Runtime class which is again a java class and call the method getRuntime(), highlighted in blue. We will pass the variable “STARTSERVER” into runtime.exec() method. It will start the Appium Server.

Once the process is started, we have to store the current state of the process into this variable. We will give a sleep time of 5 seconds as it takes time to start the process. what we are trying to validate here is, if the process is not null; it means that the process is started as highlighted in the gray box.

Stop Appium Server

Here we need to create another method named stopAppiumServer(). We again verify the state of the process and if it is not null, call a method of process class destroy().

So now we know how to start and stop the Appium server from code. Let’s try to install and launch an app on a mobile device. Let’s see how we can install a .apk file on an Android device and launch it automatically without providing the path in Appium Server.

Installing and launching the application

To begin with, we call the stopAppiumServer() method to verify if any instance of Appium Server is already running and if so, then it closes that instance, as highlighted in red. The method highlighted in yellow starts the Appium Server.

Then store the apk path file into a variable of File class, which is a Java class as highlighted in blue. Create another variable of File class app. It takes two parameters:

• The absolute path of the apk file.
• Name of the apk file.

Now the absolute path is stored into appDir variable and the name of apk file in the second part as highlighted in the green box. The rest of the things are the same as discussed in the earlier sessions.

The complete code is shown here.

Now that you have learned how to launch app from code, let’s move on to the next blog where we will learn how to set up Appium on a Mac machine.

No comments yet

In the last blog in this series, we learned how to set up Appium for test automation on a Windows machine. Now we will handle the application by writing the Java code. We will require the following software:

Eclipse

Selenium standalone Jar

Appium Java Client
 

This process consists of five steps as depicted in the picture below.

First, we need to collect the Selenium Standalone JAR and Appium Java Client Libraries. To download the Selenium standalone JAR file, go to seleniumhq.org/download then click on the Download version.

For Appium Java client you need to go to appium.io/downloads and download the libraries for the selected language.

Now to create a java project download Eclipse from eclipse.org/downloads. Launch Eclipse and select the workspace location.

To set the Android SDK path into Eclipse, click on the Windows tab in the menu bar and select Preferences in the drop-down list.

Then select the Android option and browse your Android SDK location and click on Apply.

Launch Eclipse and right-click on Package Explorer. Then select a new Java Project.

Enter a project name and click finish.

Once the project is created, add a folder to the project, for the project dependency files [Selenium Standalone] and [Appium Client Library] which you have downloaded.

Copy the downloaded file into the newly created project dependencies folder. Select both files and right-click. Then select the add to Build path option and then Add to Build Path. Thus both classes have been added to your project reference libraries.

Create a class and import the required packages. Now right click on the src folder, hover the mouse over the new option and select the Class option.

Provide a package name, the name of class then select the main method checkbox.

A .java file within the package is created in Package Explorer panel. An auto-generated the main method is generated on the right panel.

You need to define a public class variable of AndroidDriver as your first line of code. You will now see an error for an android driver. Now hover your mouse over the error, you will get a list of quick fixes. Select Import ‘AndroidDriver’. Once you select the import package option, the android driver package will be imported and the error will be removed.

Create an object of DesiredCapabilities. Again you will get an error for DesiredCapabilities. Hover the mouse over DesiredCapabilities and then select Import ‘DesiredCapabilities’ from the quick fix list.

Once you select the import package option, the DesiredCapabilities package will be imported and the error will be removed.

Now set the DesiredCapabilities and also provide the package of an application and the name of application launcher activity.

Now you need to instantiate the Android driver.

To do this we need to have two parameters, the first is the Appium server address with the port number which it is running and the Capabilities.

Hover mouse on URL and import URL from Java.net. You will get an error for complete new URL section, hover mouse on the error and select Add throws declaration. By doing so exception has been added into your main method.

Now start the Appium server and connect a device to the system. Now return to Eclipse and execute the code. This will launch the app in the device.

In the code, we have declared the class as public so that we can access it anywhere inside out test.

The java main method is highlighted in yellow. We created an object of desired capabilities class which you can see in the green box. In method setCapability, there are two parameters. First is the capability name and second is the capability value as highlighted in blue. Then we created an object of AndroidDriver class highlighted in the black box. The code highlighted in gray is the findElement(By) method which can locate an element on the screen.

Now that you have learned how to write a mobile test automation script using Appium test automation framework, we can move on to the next blog where we will learn how to start the Appium server and launch the app from code.

 
Related Articles:

No comments yet

In the previous blog, we informed about the basics of Appium and its architecture. Now let’s understand how to setup Appium. There are four steps required to setup Appium, they are enabling the Android device for test, test environment setup, Appium Configurations, Launch the app on the device.
 

Pre-requisites for Appium Mobile Testing

 
1. An Android device with OS 4.2+
2. AUT(Application Under Test) file (.apk)
3. Phone USB Drivers
4. Java (JDK)
5. Android Studio (SDK)
6. Eclipse
7. Selenium Standalone JAR
8. Appium Java Client
9. Appium for Windows
10. .NET Framework 4.5
 

Android Developer Options in device

 
Every Android smartphone contains a secret set of Android developer options which are used by app developers who need additional functions to test their apps they are making for Android devices. It allows you to enable debugging over USB, capture bug reports on your Android device and show CPU usage on the screen to measure the impact of your software.
 
To enable developer option in the phones to go to the settings, click on the about phone options and click on the build number 7 times to enable the developer options.
 

Doing so will display a toast message for enabling the developer option. the current message appears if the developer message is already enabled on the phone.
 

Phone Drivers

 
The phone can communicate with the PC only if there are proper drivers installed for the USB cable. Each phone manufacturers provides its own drivers for the phone. PDA net is a driver which works with all the Android devices. It makes sure that your phone is detected in DDMS.
 
Open pdanet.co and go to download screen and download the latest version to install it on your PC.
 

Let’s verify if the phone is prepared.
 
The ddms.bat file is present in the Android SDK tools folder.
 

Double click on the file and you will see the Dalvic Debug Monitor window.
 

If your DDMS option is enabled i.e. if you have installed the PDA net software and connected the device to the machine, that device should be detected in this monitor. Now let’s move on to the second step.
 

Test Environment Setup

 
First, you need to download JDK from the Oracle website.

Once downloaded, install it to your machine. Now you need to set the Java installation path in your Environment variable. Right-click on Computer option in the Start menu and select the Properties option. Select Advanced system settings and then select the Environment variables option in the Advanced tab.
 

Then select the new option and enter the new variable name as JAVA_HOME.
 

Set the path of JDK to variable value and then click OK.
 
To get an Android emulator you need to go to www.developer.android.com\studio#downloads and Scroll down to Command-line tools only section to download the zip file of SDK tools package for Windows.
 

Don’t download the EXE file. Once the SDK file is downloaded, copy it to the C drive, make a new folder and extract the zip file in the new folder.
 
Now you need to search for SDK manager in the bins folder and open SDK manager. Once the SDK manager window is open, go to tools and then get into the bin folder and in the address bar type cmd and hit enter. Now in the command prompt type SDK manager “platform-tools” “platforms; Android-28 and then hit enter. So now you will be able to see Platform tools and Platform folders in now folder you created for the extracted files.
Click on platform tools and copy the address bar text and then again go to an environment variable. Then go to the path, a new window will pop up, make a new path and enter the copied text there and then click on OK.
 
To download Appium go to www.appium.io and click on the Download button.
 

 
Under the latest version, click on the Appium-windows-1.12.1.exe file. Once the file is downloaded, open the appium.exe file. Click on the Start Server v1.12.1 button.
 

Then in the server window click on the Start inspection session icon at the top right corner.
 

Now you can get started with Appium automation testing. Do read our next blog to get more information about Appium mobile automation and how to inspect elements using Appium Desktop.

 
Related Articles:

No comments yet

[xyz-ihs snippet=”quickLinks-Appium”]

Appium is an open source mobile app UI testing framework. You can test all types of mobile apps and perform automation test on physical devices as well as on emulators and simulators. Appium mobile testing does not have a dependency on mobile device OS and it supports cross-platform app testing as a single API works for both Android and iOS. Appium supports many popular languages like C, PHP, Python, C#, Java, Ruby, JavaScript, etc.

What is Appium Mobile Testing?

When Appium is installed then a server is set up on your machine that exposes the REST API. It receives a command request from the client and executes that command on Android or iOS mobile devices. Then it responds back with an HTTP response. It uses mobile test automation frameworks like Apple instruments or UIAutomator2 to drive the UI of apps.

Approaches to Test Automation

There is two approaches for mobile test automation, Image-based and Object-based approach. Let’s understand both in detail.

Image-Based Approach for Test Automation

This technique of object identification is based on the image processing attributes of the objects in the Application Under Test (AUT). Example: Automate user options like “click, type, drag-drop, mouse actions, etc.”

Visual verification of the expected output

• Not dependent on the platform underneath
• Can be used to automate emulators as well as a real device.

The object-based approach of test automation

This technique of test automation is based on recognizing the nativity of the objects in AUT. This nativity reorganization process for each individual object in the application is carried out using different attributes that are assigned to the object.

It is used to extract the application object identifier with its properties from the actual native operating system source code, just like the developer used. This is an accurate and fast method to recognize the buttons, lists and other objects used by the application.

One drawback of the object-based approach is that the recognition of the individual attributes of the object involved restricts these techniques ability to function in test scenarios that require third-party application access. This reduces the automation coverage of utilizing this technique.

Which approach should we choose?

As we have seen, both approaches have their pros and cons. To get better results, you can merge both approaches and think about devising a hybrid test automation solution.

The combination of OCR (image based) and native (object-based) approach allows users to build a single script that will be portable across different devices. It will make your automation robust and efficient and allows the users to confidently detect the relevant native and GUI defect within the mobile application.

Appium Overview and Architecture

Appium is an HTTP server that manages WebDriver sessions. On iOS devices, Appium proxies command to a UI automation script running on Mac Instruments environment. Apple provides an application called instruments which are used to do a lot of activities like profiling, controlling and building iOS apps. It also provides an automation component where you can write some commands in JavaScript which uses UIAutomation APIs which interact with the app user interface. Appium mobile automation uses these same libraries to automate iOS apps.

The Webdriver Script sends a command in the form of HTTP (JSWP) to the Appium Server. Then the Appium Server will then decide as per the request which driver should be initiated. So, in this case, the Appium Server will initiate the XCUITest driver and it will pass the request to the WebdriverAgent which is an IPA (WebdriverAgent.xcproj) developed by Facebook. WebdriverAgent is responsible to send the command to the Application Under Test (AUT) to carry out the actions in the app. Then the response will be sent to the Webdriver Script through the Appium server.

Only iOS 9.3 and above version are supported by the XCUITest Driver. You can find all the capabilities for XCUITest Driver in the link mentioned below.

https://github.com/appium/appium-xcuitest-driver

The situation is very similar in the case of Android where Appium proxies command to a UIAutomator2 test case running on the device. UIAutomator2 is Android’s UI automation framework which supports running JUnit test cases directly into the device into the command line. It uses Java as the programing language but Appium will make it run from any of the web drivers supported languages.

To answer the question “what is Appium automation?”, let’s have a look at the Appium philosophy.

Appium mobile testing is required for proper execution of continuous integration as it speeds up the overall testing process. Appium mobile testing helps to run the repetitive test which would take more time to perform manually. This is why appium mobile testing is the preferred choice for the developers when it comes to test automation.

In the next blog, we will learn more about Appium mobile testing and how to install/configure the Appium setup on a windows machine.

Related Articles:

• How to use Appium Inspector for Test Automation
• Appium Setup for Windows
• Starting Appium Server and launching the app from code
• How To Install Appium On A Mac Machine
• Appium vs Espresso: The Most Popular Automation Testing Framework in 2019

No comments yet