Transform your testing process with: Real Device Features, Company-wide Licences, & App Percy
Browserstack Documentation Documentation
Documentation home icon Separator

    Integrate BrowserStack App Automate with Bitrise

    Bitrise is a mobile CI/CD Platform as a Service (PaaS) to automate the build and deploy process of your applications. It helps catch failures ahead of the production stage and mitigate them as they occur.

    In the guide, you’ll learn how to:

    Prerequisite

    Add BrowserStack App Automate - Espresso step in Bitrise

    To add the BrowserStack App Automate step in the workflow pipeline of your app, complete the following steps:

    1. Go to your Bitrise workspace and navigate to your app’s Build page.
    2. On the app’s Build page, click Edit workflow. Edit workflow in Bitrise
    3. In the Workflow Editor page, view the Workflows tab. The default steps are listed in the left pane. Click + to add a new step.
    4. Search and click the Android Build for UI testing step.

      This step builds your app and test suite file, and generates the BITRISE_APK_PATH and BITRISE_TEST_APK_PATH environment variables.

      Check out the Android Build for UI testing section to learn about configuring this step. Add Android UI test step
    5. After you configure the Android Build for UI testing step, click + under the step to add the BrowserStack step.
    6. In the steps pane, search and click BrowserStack App Automate - Espresso.

    Ensure that you’ve added the BrowserStack App Automate - Espresso step under the Android Build for UI testing step, as shown in the following image:

    Steps in Bitrise

    Configure BrowserStack App Automate - Espresso step in Bitrise

    To configure the BrowserStack App Automate - Espresso step in Bitrise, complete the following steps:

    1. Click the BrowserStack App Automate - Espresso step and view its configuration in the right pane.
    2. In the Input variables section of the BrowserStack App Automate - Espresso step, set the parameters as explained in the following table, and save it.
    Parameter Description Flag Value
    BrowserStack username Set your BrowserStack Username Required String
    BrowserStack access key Set your BrowserStack Access Key Required String
    Android app under test Set the path of your Android app (.apk) file.

    The Android Build for UI testing step generates the .apk file path and stores it in the BITRISE_APK_PATH environment variable, which you can use.

    You can add any other path of the app file.    		 Required Path to the app file

    Example: $BITRISE_APK_PATH
    Espresso test suite Set the path of your test suite (.apk) file .

    The Android Build for UI testing step generates the .apk file path and stores it in the BITRISE_TEST_APK_PATH environment variable, which you can use.

    You can add any other path of the test suite file.    		 Required Path to the test suite file

    Example: $BITRISE_TEST_APK_PATH
    Devices Set to one or more device-OS combinations in a new line.

    Check out the device-OS combinations list to set this parameter.    		 Required Example:
    Samsung Galaxy S9 Plus-9.0
    Google Pixel 3a-9.0
    Project name Provide a project name for the tests Optional String

    Note that only letters (A-Z, a-z), digits (0-9), periods (.), colons (:) and underscores (_) are allowed. Any other characters are ignored.
    Test sharding Enable test sharding to split test cases into different groups instead of running them sequentially.

    Set key-value pairs to specify the number of shards and configure its behaviour.    		 Optional Examples:

    Input for auto strategy:
    {"numberOfShards": 2}, "devices": ["Google Pixel 3-9.0"]

    Input for package strategy:{"numberOfShards": 2, "mapping": [{"name": "Shard 1", "strategy": "package", "values": ["com.foo.login", "com.foo.logout"]}, {"name": "Shard 2", "strategy": "package", "values": ["com.foo.dashboard"]}]}

    Input for class strategy: {"numberOfShards": 2, "mapping": [{"name": "Shard 1", "strategy": "class", "values": ["com.foo.login.user", "com.foo.login.admin"]}, {"name": "Shard 2", "strategy": "class", "values": ["com.foo.logout.user"]}]}
    Single runner invocation Enable to run all tests in a single instrumentation process to reduce overall build time. Check out the single runner invocation section to learn more. Optional true, false
    Default: false
    Local testing Enable Local testing to retrieve app data hosted on local/private servers. Optional true, false
    Default: false
    Test capabilities Set the key-value pairs of other capabilities provided by BrowserStack in a new line.

    Check out the Request parameters section of the execute build API request to learn about more capabilities.    		 Optional Example:
    coverage=true
    geoLocation=CN"

    To learn more parameters and output variables available in this step, check out the section on the complete list of parameters.

    Set up a trigger for Espresso build in Bitrise

    Setting up a trigger in Bitrise enables your workflow to run the pipeline when an event, such as pull request or any commit, occurs in your source repository.

    To set up a trigger in your app’s workflow, complete the following steps:

    1. On the Workflow Editor page, click the Triggers tab.
    2. In the Triggers section, select either PUSH, PULL REQUEST, or TAG type of trigger depending on your use case.
    3. Click + ADD TRIGGER and configure the trigger based on your selection.

      Check out the Bitrise triggers page to learn about trigger configurations.
    4. Save the configuration.

    You can now make changes in your source repository and the build is triggered automatically in Bitrise.

    Visit your App Automate dashboard and go to your Bitrise build to view the test result.

    View results in BrowserStack

    List of available parameters in App Automate - Espresso step

    The following table lists all parameters that you can configure using the App Automate - Espresso step:

    The parameters available in the Input variables section of the BrowserStack App Automate - Espresso step are listed in the following table:

    Parameter Description Flag Value
    BrowserStack username Set your BrowserStack Username Required String
    BrowserStack access key Set your BrowserStack Access Key Required String
    Android app under test Set the path of your Android app (.apk) file.

    The Android Build for UI testing step generates the .apk file path and stores it in the BITRISE_APK_PATH environment variable, which you can use.

    You can add any other path of the app file.    		 Required Path to the app file

    Example: $BITRISE_APK_PATH
    Espresso test suite Set the path of your test suite (.apk) file .

    The Android Build for UI testing step generates the .apk file path and stores it in the BITRISE_TEST_APK_PATH environment variable, which you can use.

    You can add any other path of the test suite file.    		 Required Path to the test suite file

    Example: $BITRISE_TEST_APK_PATH
    Devices Set to one or more device-OS combinations in a new line.

    Check out the device-OS combinations list to set this parameter.    		 Required Example:
    Samsung Galaxy S9 Plus-9.0
    Google Pixel 3a-9.0
    Instrumentation logs Generate instrumentation logs of the test session N/A It is set to true, by default, and cannot be disabled
    Network Logs Generate network logs of your Espresso test sessions to capture network traffic, latency, etc. Optional true, false
    Default: false
    Android logcat logs Generate device logs (Android logcat) during Espresso test execution Optional true, false
    Default: false
    Capture Screenshots Capture the screenshots of the test execution Optional true, false
    Default: false
    Video recording Record video of the test execution Optional true, false
    Default: true
    Project name Provide a project name for the tests Optional String

    Note that only letters (A-Z, a-z), digits (0-9), periods (.), colons (:) and underscores (_) are allowed. Any other characters are ignored.
    Filter tests Set the key-value pairs of filters to run tests from supported test filtering strategies: class, package, annotation, and size Optional Examples:
    For class filtering strategy: class com.android.foo.ClassA, class com.android.foo.ClassB,class com.android.foo.ClassC

    For package filtering strategy: package com.android.foo

    For annotation filtering strategy: size small,size medium,size large
    Test sharding Enable test sharding to split test cases into different groups instead of running them sequentially.

    Set key-value pairs to specify the number of shards and configure its behaviour.    		 Optional Examples:

    Input for auto strategy:
    {"numberOfShards": 2}, "devices": ["Google Pixel 3-9.0"]

    Input for package strategy:{"numberOfShards": 2, "mapping": [{"name": "Shard 1", "strategy": "package", "values": ["com.foo.login", "com.foo.logout"]}, {"name": "Shard 2", "strategy": "package", "values": ["com.foo.dashboard"]}]}

    Input for class strategy: {"numberOfShards": 2, "mapping": [{"name": "Shard 1", "strategy": "class", "values": ["com.foo.login.user", "com.foo.login.admin"]}, {"name": "Shard 2", "strategy": "class", "values": ["com.foo.logout.user"]}]}
    Clear app data Enable to clear app data after every test run Optional true, false
    Default: false
    Single runner invocation Enable to run all tests in a single instrumentation process to reduce overall build time. Check out the single runner invocation section to learn more. Optional true, false
    Default: false
    Notify project status Set a callback URL if you want BrowserStack to notify any third-party service about completion of build under a given project. This parameter requires that the Project name parameter also be set.

    The third-party service will receive a callback if no new builds are triggered for 5 minutes and all existing builds have completed their execution.    		 Optional URL
    Local testing Enable Local testing to retrieve app data hosted on local/private servers. Optional true, false
    Default: false
    Mock server Enable to mock a web server in your Espresso tests to mock your API responses. Optional true, false
    Default: false
    Test capabilities Set the key-value pairs of other capabilities provided by BrowserStack in a new line.

    Check out the Request parameters section of the execute build API request to learn about more capabilities.    		 Optional Example:
    coverage=true
    geoLocation=CN"
    Build Status Enable to wait for BrowserStack to complete the execution and get the test results Optional true, false
    Default: true

    When the build is executed, the BrowserStack App Automate - Espresso step generates output variables as explained in the following table:

    Output variable Description
    $BROWSERSTACK_BUILD_URL URL of the build in your App Automate dashboard
    $BROWSERSTACK_BUILD_STATUS Status of the executed build. Check out the test results guide to learn about available status.

    We're sorry to hear that. Please share your feedback so we can do better

    Contact our Support team for immediate help while we work on improving our docs.

    We're continuously improving our docs. We'd love to know what you liked






    Thank you for your valuable feedback

    • ON THIS PAGE

      Is this page helping you?

      Yes
      No

      We're sorry to hear that. Please share your feedback so we can do better

      Contact our Support team for immediate help while we work on improving our docs.

      We're continuously improving our docs. We'd love to know what you liked






      Thank you for your valuable feedback!

      We use cookies to enhance user experience, analyze site usage, and assist in our marketing efforts. By continuing to browse or closing this banner, you acknowledge that you have read and agree to our Cookie Policy, Privacy Policy and Terms of Service.

      Got it

      Talk to an Expert
      Download Copy