Mobile testing with Cucumber Appium and Ruby

https://appsierra.com/how-to-do-cross-platform-mobile-testing-with-cucumber-appium-and-ruby/

Folder structure

• 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.

Config

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:

Features

Inside the features folder, we find a folder structure and also the test scenarios, I’ll start by talking about the elements folder.

Elements

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.

Page Objects

Pages are an abstraction for creating page objects, where appium methods are paralleled with elements captured by us.

Step definitions

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.

Support

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.

Env

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.

Hooks

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.

Appium custom

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.

Rake

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.

Hello. I am a student and taking knowledge through internship about digital marketing.