In this post, we will discuss “How to do Cross-platform Mobile Testing with Cucumber Appium and ruby”.
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.
- 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 it is possible that you all are 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.
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.
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).
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.
We hope this post about Cross-platform mobile testing with cucumber appium and ruby have helped you, If so please leave your comment.