Appium Mobile Testing Framework for iOS & Android
We can say that automation is the building block in many fields. Web scraping in data science (web scraping), automation of tests in web applications, and automation of mobile software tests work in the same way. These are jobs that we are not so foreign anymore.
Step-by-Step Guide for Setting Up Appium for Auto iOS Tests
Appium is a cross-platform test automation tool that we use to run Android and IOS scripts using an open-source web drive. It is used to test native apps, mobile web apps, and hybrid apps. We can say that the Appium framework is the most used test automation framework on the market.
It was the year 2013 in which it was launched by Dan Cuellar and the beta version came in 2017.Although mobile devices provide testing on Android and IOS, it is now that the testing processes of desktop applications started.
Philosophies for Appium Mobile Testing
The Appium developer team has set 4 main philosophies for this framework, which is a rising star.
- You do not need to recompile or modify it in any way to automate your application. This makes working with this framework quite easy for the testers and developers.
- You do not need to get stuck in a specific language or frame to write and run your tests.
- The mobile automation framework should not reinvent the wheel when it comes to automation APIs.
- Appium for mobile testing, like its name, should be open source and practical.
How Does the Architecture of the Appium Project Live This Philosophy?
We do not need to compile Appium-specific or third-party codes or frameworks for the applications. This means that you are testing the same application you submitted. The frameworks provided by the application owner we use are:
- iOS 9.3 and higher: Apple’s XCUI Test
- iOS 9.3 and earlier: Apple’s UI Automation
- Android 4.2+: Google ın Ui Automator / Ui Automator2
- Windows: Microsoft’s Win App Driver
It meets requirement #2 by wrapping the frameworks provided by the application owner in the WebDriver API, a single API. WebDriver (aka ” Selenium WebDriver “) specifies a client-server protocol ( known as JSON Cable Protocol ).
Given this client-server architecture, a client written in any language can be used to send appropriate HTTP requests to the server. Customers written in every popular programming language already have.
This also means that you are free to use the test runner and test frame you want; client libraries are only HTTP clients and can be mixed into your code as desired. You have full freedom to make a choice regarding the test framework.
In other words, Appium & WebDriver clients are not technically “test frameworks” – they are “automation libraries”. In this way, you can manage your test environment as you wish! Appium meets requirement 3 in the same way: WebDriver has become the de facto standard for automating web browsers and is a W3C Working Draft.
How to Configure Appium From Scratch on Windows (Part 1)
Why do you say you are doing something completely different for mobile devices? Instead, its protocol has been expanded with additional API methods useful for mobile automation. The structures that you can reach and which have been made available before are specified with links. We think it’s a tool, framework, etc. If we use it, we need to know how the vehicle we use works, that is, its architecture.
How Does Appium Work Architecturally?
Following are the points that will show the working of Appium:
1. Client / Server Architecture
Appium is a web server that uses the Rest API. It receives connection information by the client, listens for the commands of these connections, executes these commands in a desired mobile application, and returns an HTTP response to represent the result of these commands. Having a client/server architecture provides many advantages.
You can write test codes in any language that is an HTTP client. Python and Java are our favorites ( Languages with Appium client libraries ) The server may also be a different machine than our tests are running. We can write test code and rely on a cloud service to receive and interpret commands.
2. Session
We always perform Appium automation in the context of a session. Clients are specific to each library in a way they began the session with a server, but all of the POST /session by sending a request to the server as ” desirable qualities ” that ” Desired capabilities ” object sends a JSON object called.
At this point, the server starts the automation session and responds with a session ID used to send other commands. It will be more meaningful for the Appium that we will install in the next article.
3. Desired Capabilities
The desired capabilities are a set of keys and values (i.e a map or set of information) sent to the Appium server to tell the server what kind of automation session we are interested in starting.
Various capabilities can change the behavior of the server during automation. For example, if we want to tell Appium that we want an iOS session instead of Android or Windows, we can also set its platform Name property iOS.
Or during the Safari automation session, we can set it by setting its safari Allow Popups capacity true to open new windows and use JavaScript. Desired Capabilities are keys and values encoded in a JSON object, sent by Appium clients to the server.
4. Appium Server
Appium is a server written in Node.js. Appium latest version can be built and installed from the source or installed directly from NPM : Appium server setup
5. Appium Clients
There are client libraries (Java, Ruby, Python, PHP, JavaScript, and C#) that support extensions to Appium’s WebDriver protocol. When using Appium, you may want to use these client libraries instead of your regular WebDriver client. You can see the full list of libraries here.
Now that you have enough information to start using Appium, you can congratulate yourself. This article has delineated in details about Appium mobile testing. Everything you learned here can be considered as a basis for understanding and using Appium mobile testing in a meaningful and valuable way.