Category Page

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.

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:

 

Test App
An impressive expression by Appium.io showing why to choose Appium

 

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.

 

Appium Automation Testing 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:

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.

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.

template selection
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.

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.

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

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

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.

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

Open a terminal
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.

execute the command
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.

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

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

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

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

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

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

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

Start Session
Your simulator is now connected.

17
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:

Suyash Dubey | Posted on | 2 min Read

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.
 
Appium Mobile Testing

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
 

Want to test your Mobile App?

Join pCloudy Platform!

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.
 
About Phone

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.
 
Appium Setup

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

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

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.
Oracle download

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.
 
Advanced system setting

Then select the new option and enter the new variable name as JAVA_HOME.
 
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.
 
Command line tools only

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.
 
Download Appium
 
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.
 
ApAppium Start Server v1.12.1

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

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.

Want to test your Mobile App?

Join pCloudy Platform!

 
Related Articles:

  • Writing The First Appium Test Automation Script (Android)
  • How To Install Appium On A Mac Machine
  • Basics of Appium Mobile Testing
  • Inspecting Element on pCloudy Devices Using Appium Desktop
  • Cross Platform Mobile Test Automation Using Appium
  • Appium vs Espresso

     

    Mobile app automation testing has evolved as a crucial aspect of the mobile app development process to help deliver better quality solutions, under controlled time cycles and cost schedules. But for delivering bug-free app, choosing the best suitable automation testing framework for your app is very important. There are many automation testing frameworks available in the market with exceptional capacities. This blog is all about Appium vs Espresso and we will analyze which of these two most widely used Automation testing frameworks is preferable for your app testing.

     

    Espresso was not preferred because of its flakiness and instability issues. But, from the time Google has brought Android Test Orchestrator, a Gradle test option, instability and unreliability of Android Espresso tests have vanished. This, in turn, is creating a serious problem for the most popular automation framework Appium.

     

    Let’s find out in this blog if Espresso now comes with a power to kill Appium or Appium can hold its stand in this fiercely competitive market.

    Appium vs espresso1
    Let’s get into the details.
     
    What is Appium?

    It is an open source, cross-platform mobile app automation testing framework. Appium allows native, hybrid and web app testing and supports automation test on physical devices as well as emulators or simulators. The Appium server uses selenium web driver which permits platform independence and allows the user to use the same code for Android or iOS.

     
    Advantages of using Appium

    • Facilitates test execution without server machines
    • Appium is developed using cross-platform runtime environment like NodeJs which enables programmers to write server-side code in javascript. It is designed as an HTTP server and you can run the test without requiring a server machine.

       

    • Does not require app code recompilation
    • Most of the automation testing tools require testers to alter app code. Some of the test automation frameworks require testing professionals to recompile the code according to the targeted mobile platforms. Appium enables testers to evaluate both cross-platform and native apps without recompiling and altering the code that often.

       

    • Automates various types of mobile apps
    • Testers can avoid using different automation tools for different types of apps as Appium can be used for web apps, hybrid, and native apps too. It facilitates the testing of hybrid and mobile web apps as a cross-platform test automation framework. At the same time, it enables testers to test native apps through web driver protocol.

       

    • Testers can use real devices, emulators, and simulators
    • Testers use real devices to evaluate mobile app’s usability and user experience more precisely. Although, to speed up the mobile app testing one needs to use emulators or simulators too. Appium helps testers to produce reliable test results and reduce testing time by supporting real devices, emulators and simulators.

       

    • Provides a record and playback tool
    • In Appium, testers can use the inspector to accelerate testing through record and playback functionality. Appium inspector can record the behavior of native apps by inspecting their document object model (DOM). Record and playback tool can produce test scripts in a number of programming languages.

       

    • Testers can automate apps without adding extra components
    • Testers can execute the same test across multiple mobile platforms without putting extra time and efforts or adding extra component. Appium simplifies automation by keeping complexities in Appium server.

       

    • Supports several web driver compatible languages
    • You can integrate Appium with many testing frameworks and WebDriver – compatible languages including PHP, Java, Ruby, Javascript, C# and Objective C. Hence, a tester has the option to write test scripts in his preferred programming language.

     
    Disadvantages of using Appium

    • Common gestures
    • Appium lacks commonly used gestures like double-clicking in java-client libraries. It also does not support Android alert handling directly and the users cannot evaluate alert handling through native API. Testers have to put extra time and effort to test these gestures.

       

    • No script execution on multiple iOS simulators
    • Simulators make it easier for testers to mimic internal behavior of the underlying iOS devices. Although Appium does not allow users to run multiple test scripts on multiple simulators simultaneously.

       

    • Lacks the capability to recognize images
    • Appium cannot locate and recognize images automatically to evaluate games and apps precisely. The testers have to take help of screen coordinates to make Appium locate and recognize images.

       

    • Does not support older versions of android
    • Appium supports only Android 4.2 and later and does not supports older APIs for Android. There are still many people using devices which run on older versions of Android and developers find it difficult to test mobile apps developed targeting older Android API level.

     
    What is Espresso?

    Espresso is a tool developed by Google which is used for testing the UI of Android apps. It automatically synchronizes your test actions with the user interface of the mobile app and ensures that the activity is started before the tests run.

     

    Although when you execute an Espresso test you will have shared state in separate tests and some flakiness. For this Google came up with a solution. Android Test Orchestrator is a Gradle test option that helps in testing and increases the reliability of our automated test suites.

     

    If you use Gradle build tools in any version of Android Studio below 3.0 then you also have to update the dependency setup. Let’s take a look at the advantages of using Android Espresso.

     
    Advantages of using Espresso

    • Integration with Gradle
    • The new Android Espresso now has the power of the Android Studio and Gradle that comes along with it. So now invoking your tests, running it or modifying it is just a matter of calling a Gradle command. This gives the full power of command line to the developer and makes testability much easier.

       

    • Test Orchestrator
    • The new Android Espresso comes with the power of Android Test Orchestrator that allows you to run each of your app’s tests within its own invocation of Instrumentor. It ensures that there is minimum shared state and crashes being isolated. It allows you to filter the tests that you want to run and also distribute tests across devices. This implies that you have finer control over how your tests run.

       

    • Less flakiness
    • The scalability of the test cycle in Android Espresso is high due to the synchronized method of execution. A built-in mechanism in Espresso that validates that the object is actually displayed on the screen. This saves test execution from breaking when confronted with “Objects not detected” and other errors.

       

    • It’s easy to develop Espresso test automation
    • Test automation is based on Java and JUnit which Android developers are familiar with. There is no setup or ramping up to implement quality in the in-cycle stage of the app SDLC.

       

    • Reliable and fast feedback
    • Android Espresso does not need any server to communicate with, instead, it runs side by side with the app and delivers fast results. It gives fast feedback to the code changes so that developers can move to the next bug fix.

       

    • Simple workflow
    • Espresso allows developers to build a test suite as a stand-alone APK that can be installed on the target mobile alongside the app under test and be executed quickly.

     
    Disadvantages of using Espresso

    • It requires access to the application source code
    • Without the source code, you won’t be able to do anything. Also, There is a risk to get used to the in-built test synchronization and UI – then it might be hard to work with WebDriver.

       

    • Narrow focus
    • If UI tests are required for both Android and iOS, it will be necessary to write twice, for two different systems. If tests require to work with Android outside the application (for example, open a received notification with a text message), you’ll have to use additional tools, such as UIAutomator.

       

    • Knowledge of launching Android app on emulators required
    • It is desirable to have at least minimal experience of building and launching Android applications on emulators.

     
    Conclusion

    Appium and Espresso both can be used to perform UI testing on Android app but if you have to choose one of them then you need to decide on the bases of your requirements. What kind of app is it and what kind of testing you want to perform. Developers who want to perform UI testing for their native Android app should go for Android Espresso. Although, if the test needs to support iOS and Android both and you want to test at a functional level then you can use Appium.

     
    Related Articles:

  • Automated Testing Using Espresso
  • How to use Appium Inspector for Test Automation
  • How to Run Espresso Test on Remote Devices
  • Espresso with pCloudy.com
  • Run Espresso in pCloudy Using Gradle
  • What is Robot Framework?

     

    Robot Framework is a generic keyword-driven test automation framework for acceptance level testing and acceptance test-driven development (ATDD). It has an easy-to-use tabular syntax for creating test cases and its testing capabilities can be extended by test libraries implemented either with Python or Java. Users can also create new keywords from existing ones using the same simple syntax that is used for creating test cases.

     

    Pre-Requisites (Ubuntu)

    1. Install python (sudo apt-get install python)

    2. Download and Install Py-Charms

    3. Install Python pip(sudo apt-get install python-pip)

    4. Install Appium-Python Client(pip install Appium-Python-Client)

    5. Install robot framework

    • pip install robotframework
    • pip install robotframework-appiumlibrary

    6. Download the sample project and import it in PyCharm

     

    How to run Robot-Framework on pCloudy Devices in Parallel?

     

    1. Open Controller.py and enter your MailId and ApiKey and Run

    Test Automation Framework

     

    2. Choose the devices where you want to execute your script

    Devices

     

    3. You will get the Robot Framework generated report and logs after execution

    Report and Logs

     

    Appium Desktop

     

    Appium Desktop is a point-and-click interface for using Appium and inspecting your app’s structure. With this new feature you will be able to run Inspector sessions on pCloudy. You just have to login in to your registered account, set up the desired capabilities for your test appropriately, and you’ll be able to drive your app remotely using Appium Desktop.

     

    Let’s understand this in detail:

    Overview

    Appium Desktop is a new open source GUI application for Windows, Mac, and Linux which gives you the power of the Appium automation server in a more organized manner with a flexible UI. From an Appium Beginner’s perspective – if you want to write test scripts with Appium, you would need 2 things.

     

    First, you would need to start the Appium Server. And second, you would also need a mechanism using which you can identify the controls (buttons, text boxes etc) in the mobile app which you want to automate.

    So Appium Desktop is a combination of two essential components of Appium:

     

    • Appium Server: Server instance for enabling testing (and test automation) of apps.
    • Appium Inspector: For inspecting and getting all the details of UI elements of your apps.

    Advantages of Appium Desktop

    • The Appium Desktop tool enables users to work with Appium on their desktops and use Inspector for yet better analysis of their apps.
    • Allows using desired capabilities and presets configuration for convenient use.
    • Provides the ability to switch between web-view and native app view from inspector.
    • Provides an action recorder and the code generator.

     

    How to install Appium Desktop

    Refer the link given below to know how and from where to install Appium Desktop.

    http://www.automationtestinghub.com/appium-desktop/

     

    Pre-requisites to use the tools effectively

    • Appium Desktop installed on your machine
    • APK or IPA file
    • pCloudy Account

     

    Let’s see the steps in detail

    1.Open Appium Desktop in your system and click on Start Inspector Session as shown in below screenshot.

     

    appium 2

     

    2. Click on Select Cloud Providers.

     

    Appium pCloudy 2

     

    2.1 Click on the pCloudy logo and then click on done.

    appium pCloudy 3

    2.2 You will be directed to the desired capabilities page of pCloudy in Appium Desktop.

    appium pCloudy 4

    2.3 Enter the below mentioned field details

    • pCloudy Host
    • pCloudy User Name
    • pCloudy API Key

     

    appium 5

    2.4 Once field details are inserted, set the Desired Capabilities.

    These are used to inform Appium Server that what kind of platform and application you want to automate. Click here to know about Desired Capabilities.

     

    appium pCloudy 5

    Note:

    By default, Booking duration is 10 minutes. If you wish to change the device duration, you have to change the number of minutes in the desired capabilities. For example, if you to keep the duration for 15 minutes, you have to set desired capabilities as ” pCloudy_DurationInMinutes”, 15 “

     

    3. Click on Start Session once you have entered the field details and set the Desired Capabilities.

     

    appium pCloudy 6

     

    4. Once session has started, login to your registered pCloudy account .

    After login go to Reports section and then go to My Active Session. Click this icon present under Action. You will be directed to LIVE VIEW page.

     

    Live View

    Note:

    Device will be connected as per the set Desired Capabilities. Once your app gets launched on the device you will able to see Appium Desktop view.

     

    5.Click on Select Element to start inspection .

     

    select element

    Example: In the below screenshot “Refuse” has been selected.

     

    Refuse

     

    6.Once you select the element you will be able to see interactions .

     

    Appium Demo

    Note:

    • There are three interaction given in Appium Desktop contributors. These are “Tap”, “Send keys” and “Clear” as shown in the screenshot.

     

    7. According to the selected interaction action will be performed on the device page.

     

    Tap

    As shown in the screenshot Tap has been selected.

     

    8.Click on this X icon to End the session.

     

    End Session

    Note:

    As soon as you end the session device will get released from Live view.

     

    appium 7

    Appium 1.9.0

     

    Having Appium 1.9.0 out, we find it to be a feature release, comprising multiple updates. Some of the key features brought forward in this release update are:

     

    a. Appium users have been facing unlocking device issues with older versions of Appium. This had been a big headache but Appium has resolved this issue with update 1.9.0. Even if the device remains locked, Appium 1.9.0 is very much capable to unlock the device and run your script smoothly.

     

    b. If the object is not identified anywhere in the script, you will be able to locate the error in Appium logs itself.

     

    c. Appium 1.9.0 comes with much faster execution compared to its older versions.

     

    d. The log information is more insightful and detailed than before.

     

    Let us have a look at Feature release updates below:
    (Source: https://github.com/appium/appium/releases)

     

    General

    • Full W3C Specification support.
    • Add full beta of Espresso driver
      for Android automation (used by specifying automationName capability to be
      “Espresso”).
    • Add driver for Samsung Tizen devices
    • Add -image find element strategy,
    • Fix –async-trace server argument, and rename as –long-stacktrace
    • Sample code has been moved into the main repository to aid in maintenance.
    • Fix status retrieval to speed up performance.

    iOS

    • Add support for Xcode 10 beta 5 and iOS 12 beta 5.
    • Add preliminary support for MacOS Mojave beta.
    • Add face id biometric support.
    • Fix retrieval of device time, and add optional format parameter.
    • Do not crash if there is no idevicesyslog when ending session.
    • Handle frames when page changes in Safari.
    • Add desired capabilities:
      • remoteDebugProxy – port or Unix domain socket on which a proxy for the
        remote debugger sits.
      • safariGarbageCollect – turn on/off JS garbage collection in Safari.
      • showSafariNetworkLog – print Safari network logs in the Appium server logs.
      • mjpegServerPort – port to which screenshots can be streamed.
    • Fix handling of settings updates, so simulators are not restarted unnecessarily.
    • Allow pulling of folder from real devices.
    • Add mobile: getContexts execute function, to retrieve meta-information (title,
      url, etc.) about available contexts.
    • Fix certificate retrieval and handling.
    • Fix cookie handling, to allow secure cookies.
    • Fix Safari timeout issues.
    • Add support to retrieve Safari network logs, as safariNetwork log type.

    Android

    • Update Chromedriver to v2.41.
    • Get Chrome version for Webviews in Android 7+, to find correct Chromedriver.
    • Make sure UiAutomator processes are cleaned up during test.
    • Fix handling of autoWebview capability.
    • New desired capabilities:
      • mjpegScreenshotUrl – url to stream screenshots to.
      • chromedriverUseSystemExecutable – boolean flag to use the default Chromedriver
        installed with Appium, avoiding any attempt to find correct Chromedriver.
      • disableWindowAnimation – disable window animations on device (now available
        on UiAutomator and UiAutomator2).
      • pageLoadStrategy – page load strategy for Chromedriver.
    • Allow test-only APKs to be installed.
    • Fix implicit wait handling for finding elements.
    • Better handle Unicode IME installation.
    • Relax package validation logic.
    • Fix error in UiAutomator searches with nested quotes.
    • Perform accessibility refresh when needed on UiAutomator2.
    • Improve logic for determining if apps need upgrade.
    • Fix screen recording to allow longer recordings, up to 30 minutes.

     

    Key challenge with Appium 1.9.0

    Now, we bring to you the challenge area that we have been able to identify with this release.

    • Even after using the capability automationName as uiautomatortool, we were unable to locate the object in >=Android v8.0 devices

    If you have been able to find out any workaround for this issue mentioned above, kindly share it with us in the comments section.

    pCloudy 5.1

    At each step of our journey, we aim to make your app testing robust and simpler. That’s why your feedback and requests are so important for us. We tried to incorporate them into a release structure again that makes pCloudy work better and faster for you.

     

    So here, we bring to you the fresh set of release updates that have been addressed and deployed in pCloudy 5.1.

     

    • Simpler Appium Integration Architecture: Here comes the bonanza for our Appium users! We have released a newer and simpler Appium integration architecture to simplify your Appium test execution on Android and iOS devices with pCloudy. The newer architecture make developers’ life simpler with lesser changes in the code. The older architecture demanded using APIs and also changes in your code that required some level of expertise. We addressed this issue and have come up with a simpler architecture where you need to mention some desired capabilities instead of calling APIs or doing changes in the code to run the Appium scripts. And wonder what! it just takes few minutes to integrate your existing Appium scripts with pcloudy. Check yourself here.
    •  

      pCloudy Appium Capabilities

      DesiredCapabilities capabilities = new DesiredCapabilities();
      capabilities.setCapability(“pCloudy_Username”, “Enter your email Id”);
      capabilities.setCapability(“pCloudy_ApiKey”, “Enter your API Key”);
      capabilities.setCapability(“pCloudy_ApplicationName”, “pCloudyAppiumDemo.apk”);
      capabilities.setCapability(“pCloudy_DurationInMinutes”, 5);
      capabilities.setCapability(“pCloudy_DeviceFullName”, “Samsung_GalaxyTabA_Android_7.1.1”);
      driver = new AndroidDriver(new URL(“https://device.pcloudy.com/appiumcloud/wd/hub”), capabilities);
    • Cross-browser testing made simpler: There are many widely used web browsers, but not all browsers, and versions of those browsers, work the same. A website may not look or function identically on each one, which can lead to lost revenue for an enterprise. We addressed the issue of choosing from the fixed set of browsers previously available.

      Heeding to the growing demands of our users, we have introduced the Launch and Upload browser feature for our Android users which will give him the freedom to choose the version of the browser that he wants to use. This is going to save their testing time and efforts to a great extent and also give better results for their cross browser test. To know more about it Click Here.

     

    Upload Browser

     

    • Faster Upload of Apps: We received multiple requests to speed up the process of Upload and synchronization of App/Data into the cloud. With some changes in the process, we have now succeeded to reduce the app upload and synchronization time by 42%.

      As you know, during app synchronization, the platform automatically synchronizes your data with all the 4 data centers of pCloudy. Earlier, the process was done in a series where synchronization once completed in one data center will then start in the 2nd one and so on which took a few minutes to complete. We have now changed this to a parallel process, which makes your testing 2x faster.

     

    App time saved in pCloudy 5.1
    App upload time saved in pCloudy 5.1

     

    • TouchID for iOS devices no more a blocker: Apple introduced the ability to perform authentication via TouchID to enable secure and effortless access to the device. But it turns out to be a hindrance for mobility teams while testing their iOS apps on devices over cloud. To ease out the process of authenticating TouchID manually every time, you can now bypass the TouchID verification in your apps using our utility. The bypass TouchID feature will be available for iOS devices version 10.0.0 or above. To know more about it Click Here.

     

    Touch ID

     

    Note: This feature will for now be available only for iOS and won’t support Face ID.

     

    • Integration with Slack: Since many of our customers are moving towards Slack, there was a huge demand to integrate Slack with pCloudy to enable their broadly distributed teams collaborate well. We noticed this change and hence we integrated Slack with pCloudy. It will now be easier for you to share bug related data and artifacts like Logs, screenshots etc through our Slack integration. To know more about it Click Here.

     

    Collaborate

     

    Share to Slack

    Struggling with your Appium test automation?

     

    The much awaited bonanza for Appium users is here. We are up with a newer and simpler Appium integration architecture which can simplify your Appium test automation execution on Android and iOS devices with pCloudy. The newer architecture make developers’ life simpler with lesser changes in the code. The older architecture demanded using APIs and also changes in your code that required some level of expertise. We addressed this issue and have come up with a simpler architecture where you need to mention some desired capabilities instead of calling APIs or doing changes in the code to run the Appium scripts. And wonder what! it makes you save 50% of your app testing time.

     

    Watch the video to know more about the new simpler and faster pCloudy Appium architecture.

    Pre-requisites

    • Appium Script
    • APK or IPA file
    • pCloudy Account

    The basic steps to replace your local Appium driver to pCloudy Appium Driver are given below:

    • Upload the apk/ipa from your local system to pCloudy. Check this link to know steps to upload an app for test.
    • Set pCloudy capabilities
      • pCloudy_Username: Enter the email ID with which you have registered on pCloudy. For reference, check this link

        Example: capabilities.setCapability(“pCloudy_Username”, ‘{e-mail-id}’);

      •  

      • pCloudy_ApiKey: API key is important for user’s verification. You can generate the API key from Settings page on device.pcloudy.com. Check this link to get your API key.

        Example: capabilities.setCapability(“pCloudy_ApiKey”, “{api-key}”);

      •  

      • pCloudy_ApplicationName: Enter the application name for the apk/ipa file which you already uploaded in the MyApp/Data.

        Example: capabilities.setCapability(“pCloudy_ApplicationName”, “pCloudyAppiumDemo.apk”);

      •  

      • pCloudy_DurationInMinutes: Enter the duration in minutes for which you want to run the test.

        Example: capabilities.setCapability(“pCloudy_DurationInMinutes”, 5);

      •  

      • pCloudy_DeviceFullName: If you know the device manufacturer, device name and version then enter the full device name.

        Example: capabilities.setCapability(“pCloudy_DeviceFullName”, “Samsung_GalaxyTabA_Android_7.1.1”);

        Note: If you don’t know the Device full name then you can enter pCloudy_DeviceManufacturer and pCloudy_DeviceVersion in the code and it will automatically run command on those devices.

        Example: capabilities.setCapability(“pCloudy_DeviceManafacturer”, “Samsung”);

        capabilities.setCapability(“pCloudy_DeviceVersion”, “5.0.1”);

      •  

    • Use pCloudy Appium endpoint as ” https://device.pcloudy.com/appiumcloud/wd/hub “
    • Create the Appium driver object and perform the execution

    Device capabilities and code snippets to run Appium on Single Android Native App:

     

    @BeforeMethod
    public void prepareTest() throws IOException, InterruptedException {
    DesiredCapabilities capabilities = new DesiredCapabilities();
    capabilities.setCapability(“pCloudy_Username”, “Enter your email Id”);
    capabilities.setCapability(“pCloudy_ApiKey”, “Enter your API Key”);
    capabilities.setCapability(“pCloudy_ApplicationName”, “pCloudyAppiumDemo.apk”);
    capabilities.setCapability(“pCloudy_DurationInMinutes”, 5);
    capabilities.setCapability(“pCloudy_DeviceFullName”, “Samsung_GalaxyTabA_Android_7.1.1”);
    driver = new AndroidDriver(new URL(“https://device.pcloudy.com/appiumcloud/wd/hub”), capabilities);
    }
    Note: Capabilities mentioned below are optional:
    capabilities.setCapability(“pCloudy_DeviceManafacturer”, “Samsung”);
    capabilities.setCapability(“pCloudy_DeviceVersion”, “5.0.1”);

    Appium Integration Architecture


    Device capabilities and code snippets to run Appium on Multiple Android Native Apps:

     

    @Parameters({ “deviceName” })
    @BeforeMethod
    public void prepareTest(String deviceName) throws IOException, InterruptedException {
    DesiredCapabilities capabilities = new DesiredCapabilities();
    capabilities.setCapability(“pCloudy_Username”, “Enter your email Id”);
    capabilities.setCapability(“pCloudy_ApiKey”, “Enter your API Key”);
    capabilities.setCapability(“pCloudy_ApplicationName”, “pCloudyAppiumDemo.apk”);
    capabilities.setCapability(“pCloudy_DurationInMinutes”, 5);
    capabilities.setCapability(“pCloudy_DeviceManafacturer”, deviceName);
    driver = new AndroidDriver(new URL(“https://device.pcloudy.com/appiumcloud/wd/hub”), capabilities);
    }
    Note: Capabilities mentioned below are optional:
    capabilities.setCapability(“pCloudy_DeviceVersion”, “5.0.1”);
    capabilities.setCapability(“pCloudy_DeviceFullName”, “Samsung_GalaxyTabA_Android_7.1.1”);

    Code 2


    Device capabilities and code snippets to run Appium on Single iOS Native Apps:

     

    @BeforeMethod
    public void prepareTest() throws IOException, InterruptedException {
    DesiredCapabilities capabilities = new DesiredCapabilities();
    capabilities.setCapability(“pCloudy_Username”, “Enter your email Id”);
    capabilities.setCapability(“pCloudy_ApiKey”, “Enter your API Key”);
    capabilities.setCapability(“pCloudy_ApplicationName”, “TestmunkDemo.ipa”);
    capabilities.setCapability(“pCloudy_DurationInMinutes”, 5);
    capabilities.setCapability(“pCloudy_DeviceFullName”, “Apple_iPhone6S_Ios_11.2.0”);
    driver = new IOSDriver(new URL(“https://device.pcloudy.com/appiumcloud/wd/hub”), capabilities);
    }
    Note: Capabilities mentioned below are optional:
    capabilities.setCapability(“pCloudy_DeviceManafacturer”, “Apple”);
    capabilities.setCapability(“pCloudy_DeviceVersion”, “10.3.2”);

    Code 3


    Device capabilities and code snippets to run Appium on Multiple iOS Native Apps:

     

    @Parameters({ “deviceName” })
    @BeforeMethod
    public void prepareTest(String deviceName) throws IOException, InterruptedException {
    DesiredCapabilities capabilities = new DesiredCapabilities();
    capabilities.setCapability(“pCloudy_Username”, “Enter your email-id”);
    capabilities.setCapability(“pCloudy_ApiKey”, “Enter your APIKey”);
    capabilities.setCapability(“pCloudy_ApplicationName”, “TestmunkDemo.ipa”);
    capabilities.setCapability(“pCloudy_DurationInMinutes”, 5);
    capabilities.setCapability(“pCloudy_DeviceManafacturer”, deviceName);
    driver = new IOSDriver(new URL(“https://device.pcloudy.com/appiumcloud/wd/hub”), capabilities);
    }
    Note: Capabilities mentioned below are optional:
    capabilities.setCapability(“pCloudy_DeviceVersion”, “10.3.2”);
    capabilities.setCapability(“pCloudy_DeviceFullName”, “Apple_iPhone6S_Ios_11.2.0”);

    Code 4


    Device capabilities and code snippets to run on Single iOS-Browser App:

     

    @BeforeMethod
    public void prepareTest() throws IOException, InterruptedException {
    DesiredCapabilities capabilities = new DesiredCapabilities();
    capabilities.setCapability(“pCloudy_Username”, “Enter your email-id”);
    capabilities.setCapability(“pCloudy_ApiKey”, “Enter your APIKey”);
    capabilities.setCapability(“pCloudy_DurationInMinutes”, 5);
    capabilities.setCapability(“pCloudy_DeviceFullName”, “Apple_iPhone6S_Ios_11.2.0”);
    capabilities.setBrowserName(“Safari”);
    driver = new IOSDriver(new URL(“https://device.pcloudy.com/appiumcloud/wd/hub”), capabilities);
    }
    Note: Capabilities mentioned below are optional:
    capabilities.setCapability(“pCloudy_DeviceManafacturer”, “Apple”);
    capabilities.setCapability(“pCloudy_DeviceVersion”, “10.3.2”);

    Code 5


    Device capabilities and code snippets to run on Multiple iOS-Browser App:

     

    @Parameters({ “deviceName” })
    @BeforeMethod
    public void prepareTest(String deviceName) throws IOException, InterruptedException {
    DesiredCapabilities capabilities = new DesiredCapabilities();
    capabilities.setCapability(“pCloudy_Username”, “Enter your email-id”);
    capabilities.setCapability(“pCloudy_ApiKey”, “Enter your APIKey”);
    capabilities.setCapability(“pCloudy_DurationInMinutes”, 5);
    capabilities.setCapability(“pCloudy_DeviceManafacturer”, deviceName);
    capabilities.setBrowserName(“Safari”);
    driver = new IOSDriver(new URL(“https://device.pcloudy.com/appiumcloud/wd/hub”), capabilities);
    }
    Note: Capabilities mentioned below are optional:
    capabilities.setCapability(“pCloudy_DeviceVersion”, “10.3.2”);
    capabilities.setCapability(“pCloudy_DeviceFullName”, “Apple_iPhone6S_Ios_11.2.0”);

    Multiple Browser App


    Device capabilities and code snippets to run on Single Android-Browser App:

     

    @BeforeMethod
    public void prepareTest() throws IOException, InterruptedException {
    DesiredCapabilities capabilities = new DesiredCapabilities();
    capabilities.setCapability(“pCloudy_Username”, “Enter your email-id”);
    capabilities.setCapability(“pCloudy_ApiKey”, “Enter your APIKey”);
    capabilities.setCapability(“pCloudy_DurationInMinutes”, 5);
    capabilities.setCapability(“pCloudy_DeviceManafacturer”, “Samsung”);
    capabilities.setBrowserName(“Chrome”);
    driver = new AndroidDriver(new URL(“https://device.pcloudy.com/appiumcloud/wd/hub”), capabilities);
    }
    Note: Capabilities mentioned below are optional:
    capabilities.setCapability(“pCloudy_DeviceVersion”, “5.0.1”);
    capabilities.setCapability(“pCloudy_DeviceFullName”, “Samsung_GalaxyTabA_Android_7.1.1”);

    Single Android Browser App


    Device capabilities and code snippets to run on Multiple Android-Browser Apps:

     

    @Parameters({ “deviceName” })
    @BeforeMethod
    public void prepareTest(String deviceName) throws IOException, InterruptedException {
    DesiredCapabilities capabilities = new DesiredCapabilities();
    capabilities.setCapability(“pCloudy_Username”, “Enter your email-id”);
    capabilities.setCapability(“pCloudy_ApiKey”, “Enter your APIKey”);
    capabilities.setCapability(“pCloudy_DurationInMinutes”, 5);
    capabilities.setCapability(“pCloudy_DeviceManafacturer”, deviceName);
    capabilities.setBrowserName(“Chrome”);
    driver = new AndroidDriver(new URL(“https://device.pcloudy.com/appiumcloud/wd/hub”), capabilities);
    }
    Note: Capabilities mentioned below are optional:
    capabilities.setCapability(“pCloudy_DeviceVersion”, “5.0.1”);
    capabilities.setCapability(“pCloudy_DeviceFullName”, “Samsung_GalaxyTabA_Android_7.1.1”);

    Multiple Android Browser App