2024-04-23
> Note: 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.
Mobile DevOps encourages the use of multiple mobile devices in the Cloud to tackle challenges in mobile app testing. Mobile app testing becomes challenging in a highly Android dominant fragmented mobile market.
Spawning Android virtual devices in the Cloud
QA engineers can spawn many Android virtual devices in the Cloud in parallel with Genymotion SaaS (Cloud). QA engineers can test at scale with Genymotion SaaS (Cloud).
Bitrise is a Continuous Integration & Delivery platform dedicated to mobile apps.Users can create workflows easily using the Bitrise UI.
Users can use Bitrise workflows to build, test, and deploy an app.
Users can improve efficiency by setting up the whole mobile application dev lifecycle environment.
Running Genymotion SaaS devices from Bitrise
Genymotion SaaS is available on Bitrise. QA engineers can choose Genymotion SaaS Android virtual devices to run tests on them. QA engineers can use any testing framework (Espresso, Appium, and so on) with Genymotion SaaS Android virtual devices on Bitrise.
QA engineers do not need to learn how to use the Genymotion SaaS command-line tool to automate device start and stop. Everything can be handled in the Bitrise UI.
This article covers Appium written tests. This article states that any other testing framework can also be used.
Connect your Android project to Bitrise
Adding an application to Bitrise is simple. The official documentation is available at official documentation for details.
After connecting 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
To run Appium tests, you need to build your Android application. Add the “Android build” step to your workflow.
When the “Android build” step is executed, the APK path is pushed to an environment variable.
The environment variable is $BITRISE_APK_PATH.
The workflow uses $BITRISE_APK_PATH later when running tests.
Install and start an Appium server
To run Appium tests, the workflow uses the “Script” step to install and start an Appium server. The “Script” step is a Bash script.
The Bash script allows starting an Appium server with needed capabilities. The arguments are described at here.
#!/usr/bin/env bash
# fail if any commands fails
set -e
# debug log
set -x
#export JAVA_HOME
export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
export PATH=$PATH:$JAVA_HOME/bin
npm install -g appium --unsafe-perm=true --allow-root
appium &>/dev/null &
view raw
Start Appium server
Add Genymotion SaaS start instances step
This step starts one or several devices on the Genymotion SaaS platform.
This step has several required parameters.
- Genymotion SaaS account email (required): it is the email of your Genymotion SaaS account.
If you do not have an account, 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.
Recipe UUID can be retrieved using gmsaas recipes list command line.
- ADB serial port (optional): it is the port through which the instance will be connected to ADB.
An example is localhost:adb_serial_port.
Comprehensive lists of currently available recipes UUIDs are available at here.
Run tests
In this tutorial, an Android application with Appium tests written in Python is used. Source code is public and available on Github. Even if another language is used, the logic is the same.
This section adds another “Script” step.
- Installs all dependencies.
- Starts the command executing tests.
The workflow uses the environment variable $BITRISE_APK_PATH in the test step.
The workflow exports $BITRISE_APK_PATH in the Android build step.
#!/usr/bin/env bash
# fail if any commands fails
set -e
# debug log
set -x
echo "# Install dependencies"
pip3 install -r appium/requirements.txt
# Execute tests through pytest
echo "# Execute tests"
pytest -n 2 appium/test_send_message.py --apk $BITRISE_APK_PATH
view raw
run-tests.sh
Add Genymotion SaaS stop instances step
This step stops 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”. The workflow automatically exports “Instance UUID” in the “start” step.
Conclusion
At the end of this tutorial, you should be able to create a complete Continuous Integration workflow for your application. This workflow includes unit and UI testing.
You can improve your workflow by adding other steps to deliver your application. The tutorial points to more information at here.
If you have questions, submit a request from Genymotion SaaS platform. To find more information, read documentation.
Genymotion SaaS steps are open-source.You can create an issue or contribute at 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.
Enjoy your Bitrise CI/CD workflow with Genymotion SaaS.