0Agenda of this artical is to come up with a solution to use only one test case and execute it on both android and iOS. Lets first focus on why we would need something like this.
First Lets try to answer why Organizations launch their apps on multiple platforms. Reason is: When an Organization plans to launch an app, their main objective is to reach out to maximum users. So they decide to launch their apps on most popular platforms. iOS and Android are two most popular platform today.Thats the main reason why organization simultaneously develop and launch apps on both platforms.
Now Lets focus on what it means for Mobile Dev and Mobile Test Teams.Dev teams can decide either of the following options:
i. Start development of iOS and android separately and have two teams do this.
ii. Decide to use cross platform app development tools to write only one piece of code and deploy it on both android and iOS.
iii. Both options have their own pros and cons but one main benefit of option 2 is, it results in drastically reduced development time and budget. ( Some of you may not agree with this, but this is not the main agenda of this blog)
Now can Test Teams also follow option 2?
So that test time and budget required for automating both apps is not 200%. This was the question that was hovering in mind from a long time. So i decided to give it a try to find a solution.
Lets try to understand whats needed to automate either a website or a mobile app. Irrespective of the tool used, we need to have these two facilities available to us:
i. How to interact with an element?
ii. How to find an element?
So whats the Solution. Solution is to find a tool that can give us both of these for both the platforms. Thus only tool that can be used here is - Appium.
Appium is very good for Mobile Automation and Some of the advantages of Appium are:
i. Support for multiple platforms iOS, Android and Firefox OS.
ii. Support for Native, Web and Hybrid Applications.
iii. Can be implemented in multiple languages Java, PHP, Python, Ruby, C# etc.
iv. No need to import any library in the application code.
v. Can be implemented with any Testing Framework i.e Junit, TestNG, Cucumber etc.
Our solution lies in to understand how Appium supports multiple platforms. To understand "how Appium supports multiple platforms", we need to understand Appium's architecture.
Appium Architecture: "Appium is at its heart a webserver that exposes a REST API. It receives connections from a client, listens for commands, executes those commands on a mobile device, and responds with an HTTP response representing the result of the command execution. The fact that we have a client/server architecture opens up a lot of possibilities:"
When we start appium, we have to pass some desired capabilities to appium session, which basically tells appium to start either android or iOS session. For example, if i pass desired capabilities like
"platformName" =="iOS", "deviceName"=="iPhone Simulator"
or
"platformName" =="Android", "deviceName"=="Android Emulator"
then appium would start iOS and android session respectively.
Now when we run a test case, depending on which appium session we have started, all the commands passed to Appium Server will be converted to that platform's UI Automation native commands.
How to interact with an element?
Since Appium extends Selenium Webdriver so interaction with elements is independent of the platform. For Example a button will be a button on android and iOS both and the function to interact with a button is .click() irrespective of platform. similarly for textbox, the function is .sendKeys() on both platforms.
How to find an element?
Appium cant help us much because how we find elements is dependent on platform.
iOS locators used are:
a. Name
b. Xpath
Android locators used are:
a. id
b. ClassName etc.
This issue was resolved with the help of framework where depending on which platform we want to automate, we loaded the required locators at run time.
We are created two .properties files all the locators specifies to one plateform were stored in one Properties file and specified to other were stored in other .properties file. Its work based on for which platform you want to execute the test for,locators from one of the feature files are loaded.
Automation Framework for iOS and Android Apps:
Lets go through the Framework and understand how we do this. Here is the tech stack for this framework:
Maven( Build Tool), Java ( Programming Language), Appium(Automation Tool), TestNG(Test Framework) and Page Objects (Test Design Pattern).
1. In pom.xml apart from defining normal TestNG specific tasks and targets, we have to make two profile which not only runs android and iOS test suits but also sets the value of variable "Browser" to android and iOS respectively.
2. DriverFactory.java, once pom.xml target is executed in command line , as per TestNG, control will come to function tagged with @BeforeSuite. In this function, first i check the value of system property "Browser" that was being set in pom.xml. if it is android or iOS, Appium Server server session is started accordingly.
3. Next Step is Page Objects. We have defined a page object for each page of our mobile app. But there is a twist in the constructor. Here also in the constructor i check the value of system property "Browser" that was being set in pom.xml. if it is android or iOS, locators from properties files are loaded accordingly.
4. As mentioned above, We had to deal with different locators for different platforms. Functions required to interact with elements are platform independent so there is no change in how functions are defined.
5. So now if we see our Test cases, these are normal test cases which have functions of page objects(like normal page object pattern framework test cases). Everything is handled in pom.xml, DriverFactory.java and PageObjects so there is nothing left for Test Cases.
I hope after reading this blog, your testing time for automating an app (which is on both android and iOS would come down).
Apps on android and iOS can not be 100% replica because of some platform related changes but this blog and this framework is an attempt to reduce the testing time for those parts of the app which are similar.
