This article is a reproduction of a medium article: Learn how to integrate Genymotion Cloud Android Virtual Devices into your workflows and use the testing framework of your choice on Bitrise. by Thomas Carpentier.
When it comes to testing mobile apps, especially in a highly Android dominant fragmented mobile market, it becomes challenging to perform quick and efficient tests. Mobile DevOps encourages the use of multiple mobile devices in the Cloud to tackle this challenge.
With Genymotion SaaS (Cloud), QA engineers can spawn many Android virtual devices in the Cloud in parallel and test at scale. With Bitrise, a Continuous Integration & Delivery platform dedicated to mobile apps, users can use a powerful UI to create workflows easily, which then can build, test and deploy an app and improve efficiency by setting up the whole mobile application dev lifecycle environment.
Genymotion SaaS is now available on Bitrise, so QA engineers can now easily choose the Genymotion SaaS Android virtual devices to run their tests on them using any testing framework (Espresso, Appium and so on). No need to learn how to use the Genymotion SaaS command-line tool to automate the start/stop of the devices: everything can be handled in the UI.
In this article, we are going to cover Appium written tests but you can also use any other testing framework.
Connect your Android project to Bitrise
Adding an application to Bitrise is really simple; please refer to the official documentation for details.
After having connected your Android application to bitrise.io, a workflow is created with several default Android steps. The following screenshot shows the default workflow:
Build an Android application
In order to run Appium tests, you need to build your Android application. So let’s add the “Android build” step to your workflow. When this step is executed, the APK path is pushed to an environment variable ( $BITRISE_APK_PATH ) which we will use later when we run the tests.
Install and start an Appium server
We will use the “Script” step to install and start an Appium server.
As it is a Bash script, it allows you to start an Appium server with the needed capabilities, the arguments are described here.
Add Genymotion SaaS start instances step
This step starts one or several devices on the Genymotion SaaS (Cloud) platform
This step has several required parameters:
- Genymotion SaaS account email (required): it is the email of your Genymotion SaaS account; if you don’t have an account, please create it first on https://cloud.geny.io.
- Genymotion SaaS password (required): it is the password for your Genymotion SaaS account.
- Recipe UUID (required): Recipe UUID is the identifier used when starting an instance, it can be retrieved using gmsaas recipes list command line. The comprehensive list of all currently available recipes UUIDs are available here.
- For example, if you want to start only one Android instance: e20da1a3–313c-434a-9d43–7268b12fee08
- If you want to start several Android instances, you must specify all recipe UUIDs separated by a comma, for example: e20da1a3–313c-434a-9d43–7268b12fee08,c52fdfc2–6914–4266-aa6e-50258f50ef91,06867de4–4b99–4842-ba40-fd3daaabdf23
- ADB serial port (optional): it is the port through which the instance will be connected to ADB, for example: localhost:adb_serial_port.
- If you do not specify any ADB serial ports, it will be generated randomly
- If you specify ADB serial ports, you must specify as many ports as the number of specified recipe UUID(s). ADB serial ports are separated by a comma. For example: 4321,4322,4323
In this tutorial, we use an Android application with Appium tests written in Python. Source code is public and available on Github. Even if you use another language, the logic is the same.
Here, we will add another “Script” step which:
- Installs all dependencies
- Starts the command executing tests. As you can see in the following screenshot, we use the environment variable $BITRISE_APK_PATH which has been exported in the Android build step.
Add Genymotion SaaS stop instances step
This step will stop all Genymotion SaaS instances started in the “start” step. This step will always run to make sure that no instances are left running in case a previous step fails the build.
No need to change the input variable “Instance UUID”, it is automatically exported in the “start” step.
At the end of this tutorial, you should be able to create a complete Continuous Integration workflow for your application, including unit and UI testing.
You can improve your workflow by adding other steps in order to deliver your application, but this is another story :) You can find more information here.
Genymotion SaaS steps are open-source, so feel free to create an issue or contribute https://github.com/Genymobile/bitrise-step-genymotion-cloud-saas-start and https://github.com/Genymobile/bitrise-step-genymotion-cloud-saas-stop
The Android application code sample used in this tutorial is available on Github.
Last but not least, enjoy your Bitrise CI/CD workflow with Genymotion SaaS!