Cross-Platform Mobile Automation Testing With Cucumber Appium And Ruby
In this post, we will discuss “How to do Cross-platform Mobile automation Testing with Cucumber Appium and ruby”.
The mobile automation process is generally faced by the question- Should we concoct a single test for both Android and iOS or should we develop separate tests or frameworks for each?
This question has no right or wrong answer. This is because the development teams generally give priority to ‘OS naturalization’ over ‘Design consistency across platforms’. Similarly, other teams may prefer the other alternative.
The tests which you select may also depend upon the respective programming languages and frameworks. Some native libraries for iOS and Android require separate data for each model.
You can take advantage of the PageFactory library in Java. This library allows you to locate elements based on the platform. Hence it is much easier to make your tests cross-platform. But PageFactory does not work with all major programming languages.
The first thing we needed to develop was screen mapping. There are distinct steps which need to be implemented separately. The basis of the test, methods, and execution scenarios is only one for both platforms.
Why use Ruby, Cucumber, and Appium?
How to overcome difficulties when creating automated mobile tests on multiple platforms (Android and iOS)? Creating tests for mobile devices is more complicated due to the specific characteristics of each device.
Is it possible to write a single test for both? Yes, it’s possible. We use the rake to select settings and search for screen elements. After that, page objects take care of making the screen methods.
What language would you have to use? What about the learning curve? The main proposals were Java and Ruby. Java would have many dependencies, such as having a larger learning curve and always relying on an IDE. Ruby, on the other hand, has proven much more practical in learning, has easy code reading and easy execution, not depending on an IDE.
So the solution was almost ready, we just needed to model with the chosen language.
Mobile Automation: Appium Cucumber for Android&iOS + Jenkins | Udemy
app: Where we put android and iOS apps inside their respective folders, getting app/android/app.apk and app/ios/app.ipa
config: Where we put the settings passed to the appium_lib, also in their respective folders config/android/appium.txt and config/ios/appium.txt
features: Inside the folder, we find the core of the application, which contains the elements of the views, the test scenarios, the page objects and steps of the tests. Inside also has the folder called support where we have some auxiliary classes for use.
rake_tasks: this is where much of the magic happens, where you can run a test for a particular platform with a simple command.
The configuration is a very simple part and you all may be already familiar to everyone. The thing that was modified was the use of text files for the storage of these settings.
Inside the config/android folder was the appium.txt file:
Inside the config/ios folder was the file also with the name appium.txt:
Inside the features folder, we find a folder structure and also the test scenarios, I’ll start by talking about the elements folder.
Within the elements folder, we find several YAML files. YAML is a human-readable data serialization format inspired by languages such as XML has the following structure.
These YAML files are divided by app screens. Thus facilitating the search for elements and being possible to implement the logic of the test, before the screen is ready.
Pages are an abstraction for creating page objects, where appium methods are paralleled with elements captured by us.
Mobile automation using selenium, appium & cucumber framework
This is already a common structure when we work with Cucumber and Ruby testing, where we implement the logic of cucumber and ruby test scenarios for execution. You can also use the appium tool in this regard.
Within the support folder, we implement all the helper files, either for the definition of the environment. The abstraction of some functions of Appium, the functions that map the screen, and also some hooks.
Screen mappings implements
Inside the support folder, we place a file named “screen_mappings_implements.rb” with only one function inside it, mapping the elements by platform received in this function. This function receives a screen and a package so that it can differentiate between screens and teams within the same automation.
The “env.rb” file is where we made all the logic of the environments to search the settings of each platform and also load in Appium for a given platform.
The only function in the file is“load_appium_configuration” that receives the platform. This function is responsible for uploading the file with the Appium settings for each platform.
Below we have some security checks and a case to check if it is android or ios. We store this info in a variable named caps (capabilities).
Also read: Learn All About Resolution Scaling
Finally, we made Appium Driver.new for the settings to come out working for both iOS and Android.
We have a file named hooks.rb. This file is responsible for containing Before and After, to give the start and quit at the beginning and end of each test.
And lastly, we have the “appium_custom.rb” which is the customization of some methods of “appium_lib“, simply abstracting them so that I use only one method independent of the platform or location.
And to finish with the independent execution of each test, we created a file “.rake” to make the test reports call the cucumber and use the tags that cucumber provides.
So we get to the point where using only the command “rake run_acceptance[android,@suatag]“. Now we can run a test for each platform with less code rewrite. Without performing duplication of scenarios and being more agile in the composition of tests.
Let’s wrap it up!
We hope this post about Cross-platform mobile testing and cucumber, ruby and appium automation has helped you, If so please leave your comment!