Jeroline | Posted on January 17, 2025January 20, 2025 | 2 min Read Home > Blog > Appium vs Espresso: The Most Popular Automation Testing Framework Appium vs Espresso: The Most Popular Automation Testing Framework Mobile app automation testing has become essential for ensuring the quality and performance of apps in today’s competitive market. With shorter release cycles and tighter budgets, choosing the right automation testing framework can significantly impact your app’s success. While there are many automation frameworks available, Appium and Espresso have emerged as two of the most widely used frameworks for mobile app testing. This blog provides a detailed comparison of Appium vs Espresso, highlighting their strengths, weaknesses, and ideal use cases to help you decide which framework is right for your needs. 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. What is Appium? Appium is an open-source, cross-platform mobile automation testing framework that supports the testing of native, hybrid, and web apps. It enables testing on real devices, emulators, and simulators, making it a versatile choice for mobile app testing. Appium’s architecture uses the Selenium WebDriver protocol, which allows cross-platform compatibility, enabling the same test scripts to work for both Android and iOS apps. Advantages of Using Appium Facilitates Test Execution Without a Server Machine Appium is built on a Node.js-based runtime, making it lightweight and capable of running on local machines without requiring a dedicated server. No App Code Recompilation Required Appium enables testers to run automation tests without modifying or recompiling the app code, making it highly flexible for both native and cross-platform apps. 3. Automates Various Types of Mobile Apps Whether it’s a web, hybrid, or native app, Appium supports automation across all app types using the same framework. 4. Supports Real Devices, Emulators, and Simulators Appium enables testers to run tests on real devices for accurate usability testing while also supporting emulators and simulators for faster test execution. 5. Record and Playback Tool for Quick Test Creation Appium’s inspector allows testers to record app behavior and generate scripts in multiple programming languages such as Java, Python, Ruby, and C#. 6. Cross-Platform Compatibility Appium enables you to run the same test script on both Android and iOS platforms, reducing the effort required for cross-platform app testing. 7. Supports Multiple Programming Languages Appium integrates with WebDriver-compatible languages, including Java, JavaScript, Python, PHP, Ruby, C#, and Objective-C, allowing testers to write scripts in their preferred language. Disadvantages of Using Appium Limited Gesture Support Common mobile gestures, such as double-tap, may not be natively supported in Appium’s Java-client libraries, requiring workarounds. 2. No Support for Concurrent iOS Simulator Testing Appium does not allow running multiple test scripts on iOS simulators concurrently, which can slow down large-scale iOS testing. 3. Limited Image Recognition Capability Appium struggles with image-based testing as it cannot recognize images automatically and requires screen coordinates for locating visual elements. 4. No Support for Older Android Versions Appium only supports Android 4.2 and above, making it difficult to test apps targeting older Android APIs. What is Espresso? Espresso is Google’s UI testing framework for Android apps. It provides fast, reliable UI testing by synchronizing test actions with the app’s user interface and ensuring that the app’s activities have completed before the test starts. With the introduction of Android Test Orchestrator, Google has addressed common issues like flaky tests and shared states, making Espresso more stable and reliable. Advantages of Using Espresso Integration with Gradle Espresso is fully integrated with Android Studio and Gradle, enabling developers to run tests directly from the command line or IDE with minimal setup. Android Test Orchestrator for Reliability The Android Test Orchestrator runs each test in its own sandboxed environment, ensuring minimal shared state and isolating crashes, leading to more reliable test results. 3. Less Flakiness Espresso’s built-in synchronization mechanism ensures that test actions are executed only when the app’s UI is idle, reducing flakiness caused by asynchronous operations. 4. Developer-Friendly Test Automation Since Espresso is based on Java and JUnit, Android developers can quickly adopt it without additional learning curves or external dependencies. 5. Fast Feedback Loop Unlike Appium, Espresso runs alongside the app without requiring a server, resulting in faster test execution and immediate feedback. 6. Simple Test Suite Management Espresso allows developers to package their tests as standalone APKs, which can be installed alongside the app and executed easily. Disadvantages of Using Espresso 1.Requires Access to the App’s Source Code Espresso requires access to the app’s source code, limiting its use for black-box testing or when working with third-party apps. 2. Narrow Focus (Android-Only) Espresso is designed exclusively for Android, so separate frameworks (like XCTest) are required for iOS testing, resulting in increased effort for cross-platform apps. 3. Requires Emulator Experience Running Espresso tests requires familiarity with launching and managing Android apps on emulators, which may add complexity for QA teams unfamiliar with Android development. Appium vs Espresso: Key Differences Criteria Appium Espresso Platform Support Android and iOS Android only Source Code Access Not required Required Test Type Black-box and white-box testing Primarily white-box testing Programming Language Supports multiple languages (Java, Python, C#, etc.) Java and Kotlin (via JUnit) Test Execution Requires Appium server Runs directly in the app process Cross-Platform Yes No Test Reliability May face flakiness due to external dependencies High reliability with built-in synchronization Integration Requires WebDriver integration for advanced features Fully integrated with Android Studio When to Use Appium When you need to perform cross-platform testing for both iOS and Android apps. When you require black-box testing without access to the app’s source code. When you want to use a familiar WebDriver-based framework with support for multiple languages. When to Use Espresso When you are building a native Android app and need fast, reliable UI testing. When you need a developer-friendly testing framework that integrates seamlessly with Android Studio. When you prioritize faster feedback loops for CI/CD pipelines. Conclusion Both Appium and Espresso offer powerful capabilities for mobile app testing, but the right choice depends on your app’s requirements. If you need a cross-platform solution that supports both Android and iOS, Appium is the better option. However, if you’re focused solely on Android and need a reliable, fast UI testing framework, Espresso is ideal. Comprehensive Test Coverage Test your apps on 5000+ real device and browser combinations and ensure a complete test coverage. Get a free demo
Priyanka Charak | Posted on March 6, 2023August 3, 2023 | 2 min Read Home > Blog > 12 Common Appium Mobile Test Automation Mistakes and How to Avoid Them 12 Common Appium Mobile Test Automation Mistakes and How to Avoid Them 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.
Priyanka Charak | Posted on February 16, 2023October 30, 2024 | 2 min Read Home > Blog > 5 Reasons Why Appium is The Best Mobile Automation Testing Tool on Device Cloud 5 Reasons Why Appium is The Best Mobile Automation Testing Tool on Device Cloud 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: 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. 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:
Mallikharjun | Posted on September 12, 2019December 27, 2022 | 2 min Read Home > Blog > How To Install Appium On A Mac Machine How To Install Appium On A Mac Machine 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
Suyash Dubey | Posted on July 17, 2019November 11, 2024 | 2 min Read Home > Blog > Appium Setup for Windows Appium Setup for Windows 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 Want to test your Mobile App? Join pCloudy Platform! Signup for Free 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. Want to test your Mobile App? Join pCloudy Platform! Signup for Free 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
Shivani Sinha | Posted on October 3, 2018July 31, 2019 | 2 min Read Home > Blog > Python + Appium + Robot Framework Python + Appium + Robot Framework 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 2. Choose the devices where you want to execute your script 3. You will get the Robot Framework generated report and logs after execution
Shivani Sinha | Posted on September 28, 2018September 4, 2022 | 2 min Read Home > Blog > Inspecting Element on pCloudy Devices Using Appium Desktop Inspecting Element on pCloudy Devices Using Appium Desktop 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. 2. Click on Select Cloud Providers. 2.1 Click on the pCloudy logo and then click on done. 2.2 You will be directed to the desired capabilities page of pCloudy in Appium Desktop. 2.3 Enter the below mentioned field details pCloudy Host pCloudy User Name pCloudy API Key 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. 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. 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. 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 . Example: In the below screenshot “Refuse” has been selected. 6.Once you select the element you will be able to see interactions . 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. As shown in the screenshot Tap has been selected. 8.Click on this X icon to End the session. Note: As soon as you end the session device will get released from Live view.
Shivani Sinha | Posted on September 7, 2018September 4, 2022 | 2 min Read Home > Blog > Appium 1.9.0 – Key Features and Challenge Appium 1.9.0 – Key Features and Challenge 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.
Shivani Sinha | Posted on July 27, 2018September 4, 2022 | 2 min Read Home > Blog > pCloudy 5.1 – July Release Update and Full Speed Ahead in the Third Quarter pCloudy 5.1 – July Release Update and Full Speed Ahead in the Third Quarter 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. 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 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. 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.
Shivani Sinha | Posted on July 18, 2018December 18, 2024 | 2 min Read Home > Blog > Appium Integration Architecture Redefined! Appium Runs Become Simpler with pCloudy Appium Integration Architecture Redefined! Appium Runs Become Simpler with pCloudy 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 linkExample: 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”); 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”); 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”); 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”); 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”); 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”); 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”); 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”);