Integrate Your Test Suite with BrowserStack
BrowserStack gives you instant access to our Selenium Grid of 3000+ real devices and desktop browsers. Running your Selenium tests with JUnit 5 on BrowserStack is simple.
Setup authentication
Set environment variables for BrowserStack credentials
Save your BrowserStack credentials as environment variables and use those environment variables in your code.
# Set these values in your ~/.zprofile (zsh) or ~/.profile (bash)
export BROWSERSTACK_USERNAME="YOUR_USERNAME"
export BROWSERSTACK_ACCESS_KEY="YOUR_ACCESS_KEY"
setx BROWSERSTACK_USERNAME "YOUR_USERNAME"
setx BROWSERSTACK_ACCESS_KEY "YOUR_ACCESS_KEY"
set BROWSERSTACK_USERNAME=YOUR_USERNAME
set BROWSERSTACK_ACCESS_KEY=YOUR_ACCESS_KEY
Update your Test suite config file
Once you set your BrowserStack credentials through environment variables, it will be automatically fetched from the BstackRunner.java file while executing your test script. Next, point the Selenium hub to the BrowserStack remote hub URL.
If you don’t have a config file already setup, you can download BrowserStack sample config file as a base config.
Connect your website under test
BrowserStack can integrate with test suites pointing to your localhost URL, staging environment and even websites behind one or more proxies/firewalls.
- Language Bindings
- CLI Interface - Binary
Install the package
Install the Local binary by adding it as a dependency in the pom.xml
file.
Set the access key and use available methods in your test script
Set your access key that is used to create the secure tunnel. Use the following methods provided by the local library to manage your local connection:
Method | Description |
---|---|
bsLocal.start(bsLocalArgs) |
Expects bsLocalArgs object. Returns a callback when the tunnel has started successfully. Your test script should start executing after this callback has been invoked. |
bsLocal.stop() |
Call this method after your test suite is complete. |
bsLocal.isRunning() |
Check if the BrowserStack local instance is running. |
Add the local capability to enable BrowserStack Local
Copy and set the local
capability to true
. You may face errors running your test script if any other capability is enabled before setting up local
.
If your staging environment is behind a proxy or firewall, additional arguments, such as proxy username, proxy password, etc, need to be set. Check out Local Binary parameters to learn about additional arguments.
Run a test using BrowserStack Local
Try running a localhost after completing the above steps. Check out our sample Git repository for more details.
Download BrowserStack Local
Unzip the binary
Unzip the downloaded file and move it to a folder/directory from which you have permission to start it using your command line or terminal.
Run the binary using your command line or terminal
Run the following command to initiate the BrowserStack Local connection
# Step 3 - Run this command in your terminal to start the BrowserStack Local binary. Your working directory should be where you have the downloaded binary.
./BrowserStackLocal --key YOUR_ACCESS_KEY
# Step 3 - Run this command in your command prompt. Your working directory should be where you have unzipped BrowserStackLocal.exe
BrowserStackLocal.exe --key YOUR_ACCESS_KEY
If your staging environment is behind a proxy or firewall, additional arguments, such as proxy username, proxy password, etc, need to be set. Check out Local Binary parameters to learn about additional arguments.
Add the local capability to enable BrowserStack Local
Copy and set the local
capability to true
. You may face errors running your test script if any other capability is enabled before setting up local
.
Migrate your test cases
This section will help you with all the config changes, commonly used features, and best practices for a smooth migration of your test cases to BrowserStack.
Run test suite on a single browser
We recommend running your build using a single browser like Chrome or Firefox to begin with. This will isolate issues during the migration phase and help with faster debugging. Refer the capabilities as shown to use Chrome.
Once you’ve migrated your test cases or have achieved stability with Chrome or Firefox, you can set up cross-browser testing.
Organize tests
Use the following capabilities for naming your tests and builds. This ensures effective debugging, test reporting, and build execution time analysis.
Capability | Description |
---|---|
sessionName |
Name for your test case. For example, Homepage - Get started
|
buildName |
CI/CD job or build name. For example, Website build #23 , staging_1.3.27
|
projectName |
Name of your project. For example, Marketing Website
|
Use a new buildName
name every time you run your test cases. This ensures that sessions are logically grouped under a unique build name and helps you monitor the health of your test suite effectively.
A build can only have a maximum of 1000 tests and post that a new build gets created with a ‘-1’ suffixed to the original build name.
Mark test as passed or failed
To mark whether your test has passed or failed on BrowserStack, use the Javascript executor in your test script. You can mark a test as passed
or failed
based on your test assertions.
The arguments passed in the Javascript method for setting the status and the corresponding reason of the test are status
and reason
-
status
accepts eitherpassed
orfailed
as the value -
reason
accepts a string value
Set up debugging capabilities
Use the following common debugging capabilities for your tests:
- Set the the
debug
capability to enable visual logs and capture screenshots at every Selenium command automatically. - Console Logs with log level ‘errors’ are enabled by default. Set the
consoleLogs
capability to enable different log levels, such aswarnings
,info
,verbose
,errors
, anddisable
. - Set the
networkLogs
capability to capture the browser’s performance data such as network traffic, latency, HTTP requests, and responses in a HAR format.
Commonly used features and advanced-use cases
Here’s a list of features and capabilities you may find useful.
Accept insecure certificates
This capability suppresses browser popups warning about self-signed certificates usually found in staging environments.
Capability | Expected values |
---|---|
acceptInsecureCerts |
A boolean. Default is False .True if you want to accept all SSL certificates. |
Change desktop resolution
This capability changes the default desktop screen resolution for your tests on BrowserStack infra.
Capability | Description | Expected values |
---|---|---|
resolution |
Set the resolution of your remote machine before beginning your test | A string. Default resolution is 1024x768 Supported resolutions: Windows (XP, 7): 800x600 , 1024x768 , 1280x800 , 1280x1024 , 1366x768 , 1440x900 , 1680x1050 , 1600x1200 , 1920x1200 , 1920x1080 , and 2048x1536 Windows (8, 8.1, 10): 1024x768 , 1280x800 , 1280x1024 , 1366x768 , 1440x900 , 1680x1050 , 1600x1200 , 1920x1200 , 1920x1080 , and 2048x1536 OS X (Sequoia, Sonoma, Ventura, Monterey, Big Sur, Catalina, Mojave, and High Sierra): 1024x768 , 1280x960 , 1280x1024 , 1600x1200 , 1920x1080 , 2560x1440 , 2560x1600 , and 3840x2160 OS X (All other versions): 1024x768 , 1280x960 , 1280x1024 , 1600x1200 , and 1920x1080
|
Others
Some of the additional capabilities that you might find usefule are:
Run test suite on a single browser
We recommend running your build using a single browser like Chrome or Firefox to begin with. This will isolate issues during the migration phase and help with faster debugging. Refer the capabilities as shown to use Chrome.
Once you’ve migrated your test cases or have achieved stability with Chrome or Firefox, you can set up cross-browser testing.
Organize tests
Use the following capabilities for naming your tests and builds. This ensures effective debugging, test reporting, and build execution time analysis.
Capability | Description |
---|---|
name |
Name for your test case. For example, Homepage - Get started
|
build |
CI/CD job or build name. For example, Website build #23 , staging_1.3.27
|
project |
Name of your project. For example, Marketing Website
|
Use a new build
name every time you run your test cases. This ensures that sessions are logically grouped under a unique build name and helps you monitor the health of your test suite effectively.
A build can only have a maximum of 1000 tests and post that a new build gets created with a ‘-1’ suffixed to the original build name.
Mark test as passed or failed
To mark whether your test has passed or failed on BrowserStack, use the Javascript executor in your test script. You can mark a test as passed
or failed
based on your test assertions.
The arguments passed in the Javascript method for setting the status and the corresponding reason of the test are status
and reason
-
status
accepts eitherpassed
orfailed
as the value -
reason
accepts a string value
Set up debugging capabilities
Use the following common debugging capabilities for your tests:
- Set the
browserstack.debug
capability to enable visual logs and capture screenshots at every Selenium command automatically. - Console Logs with log level ‘errors’ are enabled by default. Set the
browserstack.console
capability to enable different log levels, such aswarnings
,info
,verbose
,errors
, anddisable
. - Set the
browserstack.networkLogs
capability to capture the browser’s performance data such as network traffic, latency, HTTP requests, and responses in a HAR format.
Commonly used features and advanced-use cases
Here’s a list of features and capabilities you may find useful.
Accept insecure certificates
This capability suppresses browser popups warning about self-signed certificates usually found in staging environments.
Capability | Expected values |
---|---|
acceptSslCerts |
A boolean. Default is False .True if you want to accept all SSL certificates. |
Change desktop resolution
This capability changes the default desktop screen resolution for your tests on BrowserStack.
Capability | Description | Expected values |
---|---|---|
resolution |
Set the resolution of your remote machine before beginning your test | A string. Default resolution is 1024x768 Supported resolutions: Windows (XP, 7): 800x600 , 1024x768 , 1280x800 , 1280x1024 , 1366x768 , 1440x900 , 1680x1050 , 1600x1200 , 1920x1200 , 1920x1080 , and 2048x1536 Windows (8, 8.1, 10): 1024x768 , 1280x800 , 1280x1024 , 1366x768 , 1440x900 , 1680x1050 , 1600x1200 , 1920x1200 , 1920x1080 , and 2048x1536 OS X (Sequoia, Sonoma, Ventura, Monterey, Big Sur, Catalina, Mojave, and High Sierra): 1024x768 , 1280x960 , 1280x1024 , 1600x1200 , 1920x1080 , 2560x1440 , 2560x1600 , and 3840x2160 OS X (All other versions): 1024x768 , 1280x960 , 1280x1024 , 1600x1200 , and 1920x1080
|
This capability changes the default desktop screen resolution for your tests on BrowserStack infra.
Others
Some of the additional capabilities that you might find usefule are:
Next steps
Once you have successfully integrated your test suite with BrowserStack, you might want to check the following:
- Generate a list of capabilities that you want to use in tests
- Find information about your Projects, Builds and Sessions using our REST APIs
- Set up your CI/CD: Jenkins, Bamboo, TeamCity, Azure, CircleCI, BitBucket, TravisCI, GitHub Actions
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
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!