Skip to main content

Running instrumented tests for Android apps

Abstract

Instrumented tests run on Android devices, whether physical or emulated. On Bitrise, you can run instrumented tests using the adb tool.

Instrumented tests run on Android devices, whether physical or emulated. On Bitrise, you can run instrumented tests using the adb tool. To run your instrumented tests, you need two Steps in your Workflow:

  • The Android Build for UI testing Step builds both an APK and a test APK. For example, MyappDebug.apk and MyAppDebugAndroidTest.apk. The Step stores the path to these APKs in two output Environment Variables: BITRISE_APK_PATH and BITRISE_TEST_APK_PATH. You can use these Env Vars to access the APKs in subsequent Steps in the same Workflow.

  • The Android Instrumented Test Step runs the instrumented tests using the APKs built in the previous Step.

To run instrumented tests for Android:

Workflow Editor

bitrise.yml

  1. Add the Android Build for UI testing Step to your Workflow.

  2. Make sure the Project location input points to the root directory of your Android app.

  3. Set the module and the variant you want to build in the Module and the Variant input.

    You can check the available modules and variants of your project in the Project window in Android Studio.

    build-for-ui-testing.png

  4. In the Options input group, you can set the location for the generated APK files in the APK location pattern input.

    The input takes a file pattern as a value. The default value is */build/outputs/apk/*.apk.

  5. Optionally, you can pass additional Gradle arguments to the build task in the Additional Gradle Arguments input.

  6. Add the Android Instrumented Test Step to the Workflow, at some point after the Android Build for UI testing Step.

  7. Make sure that the Main APK path and the Test APK path inputs point to the correct location.

    By default, the values of the two inputs are the BITRISE_APK_PATH and the BITRISE_TEST_APK_PATH Environment Variables, respectively. These variables are exported by the Android Build for UI testing Step. As such, in the vast majority of cases, you don't have to modify the value of these inputs.

    android-instrumented.png

  8. In the Test runner class input, specify the test runner you wish to use.

    The default runner is the AndroidJUnitRunner class.

  9. Optionally, you can pass additional options to the test runner with the Additional testing options input.

    With this input, you issue commands to the activity manager tool of the adb shell. For more information about the commands you can issue, see the official documentation for adb.

  10. Add the Deploy to Bitrise.io Step to your Workflow to view test results: Deploying and viewing test results.

  1. Add the android-build-for-ui-testing Step to your Workflow.

      steps:
    - git-clone: {}
    - android-build-for-ui-testing:
        inputs:
    - deploy-to-bitrise-io: {}

  2. Make sure the project_location input points to the root directory of your Android app.

      steps:
    - git-clone: {}
    - android-build-for-ui-testing:
        inputs:
        - project_location: $BITRISE_SOURCE_DIR
    - deploy-to-bitrise-io: {}

  3. Set the module and the variant you want to build in the module and the variant input.

    You can check the available modules and variants of your project in the Project window in Android Studio.

      steps:
    - git-clone: {}
    - android-build-for-ui-testing:
        inputs:
        - module: app
        - variant: debug
        - project_location: $BITRISE_SOURCE_DIR
    - deploy-to-bitrise-io: {}

  4. In the apk_path_pattern input, you can set the location for the generated APK files.

    The input takes a file pattern as a value. The default value is */build/outputs/apk/*.apk.

      steps:
    - git-clone: {}
    - android-build-for-ui-testing:
        inputs:
        - arguments: flag
        - module: app
        - variant: debug
        - apk_path_pattern: '*/build/outputs/apk/*.apk'
        - project_location: $BITRISE_SOURCE_DIR
    - deploy-to-bitrise-io: {}

  5. Optionally, you can pass additional Gradle arguments to the build task in the arguments input.

      steps:
    - git-clone: {}
    - android-build-for-ui-testing:
        inputs:
        - arguments: --task
        - module: app
        - variant: debug
        - apk_path_pattern: '*/build/outputs/apk/*.apk'
        - project_location: $BITRISE_SOURCE_DIR
    - deploy-to-bitrise-io: {}

  6. Add the android-instrumented-test Step to the Workflow, at some point after the android-build-for-ui-testing Step.

      steps:
    - git-clone: {}
    - android-build-for-ui-testing:
        inputs:
        - arguments: flag
        - module: app
        - variant: debug
        - apk_path_pattern: '*/build/outputs/apk/*.apk'
        - cache_level: all
        - project_location: $BITRISE_SOURCE_DIR
    - android-instrumented-test:
        inputs:
    - deploy-to-bitrise-io: {}

  7. Make sure that the main_apk_path and the test_apk_path inputs point to the correct location.

    By default, the values of the two inputs are the BITRISE_APK_PATH and the BITRISE_TEST_APK_PATH Environment Variables, respectively. These variables are exported by the android-build-for-ui-testing Step. As such, in the vast majority of cases, you don't have to set the value of these inputs.

      steps:
    - git-clone: {}
    - android-build-for-ui-testing:
        inputs:
        - arguments: flag
        - module: app
        - variant: debug
        - apk_path_pattern: '*/build/outputs/apk/*.apk'
        - cache_level: all
        - project_location: $BITRISE_SOURCE_DIR
    - android-instrumented-test:
        inputs:
        - main_apk_path: $BITRISE_APK_PATH
        - test_apk_path: $BITRISE_TEST_APK_PATH
    - deploy-to-bitrise-io: {}

  8. In the test_runner_class input, specify the test runner you wish to use.

    The default runner is the AndroidJUnitRunner class.

      steps:
    - git-clone: {}
    - android-build-for-ui-testing:
        inputs:
        - arguments: flag
        - module: app
        - variant: debug
        - apk_path_pattern: '*/build/outputs/apk/*.apk'
        - cache_level: all
        - project_location: $BITRISE_SOURCE_DIR
    - android-instrumented-test:
        inputs:
        - test_runner_class: androidx.test.runner.AndroidJUnitRunner
        - main_apk_path: $BITRISE_APK_PATH
        - test_apk_path: $BITRISE_TEST_APK_PATH
    - deploy-to-bitrise-io: {}

  9. Optionally, you can pass additional options to the test runner with the additional_testing_options input.

    With this input, you issue commands to the activity manager tool of the adb shell. For more information about the commands you can issue, see the official documentation for adb. For example, the value KEY1 true KEY2 false will be passed to adb as adb shell am instrument -e "KEY1" "true" "KEY2" "false" [...].

      steps:
    - git-clone: {}
    - android-build-for-ui-testing:
        inputs:
        - arguments: flag
        - module: app
        - variant: debug
        - apk_path_pattern: '*/build/outputs/apk/*.apk'
        - cache_level: all
        - project_location: $BITRISE_SOURCE_DIR
    - android-instrumented-test:
        inputs:
        - test_runner_class: androidx.test.runner.AndroidJUnitRunner
        - additional_testing_options: KEY1 true KEY2 false
        - main_apk_path: $BITRISE_APK_PATH
        - test_apk_path: $BITRISE_TEST_APK_PATH
    - deploy-to-bitrise-io: {}

  10. Add the Deploy to Bitrise.io Step to your Workflow to view test results: Deploying and viewing test results.

In this section:

A Step is a block of script execution that encapsulates a build task on Bitrise: the code to perform that task, the inputs and parameters you can define for the task, and the outputs the task generates.

A Workflow is a collection of Steps, Environment Variables, and other configurations. When Bitrise starts a build, it runs one or more Workflows according to the configuration defined in the bitrise.yml file.