Integrating Robot Framework with Browserstack…

A piece of rainbow cake!

How many times have you downloaded a WebDriver for your local GUI tests? I didn’t keep count but if I got 10 cents for every download, I could have bought a nice rainbow cake by now!

In order to run Robot Framework GUI tests via Azure DevOps and enable continuous testing, I started installing WebDrivers on build agents… and kept installing… and installing … I asked myself: wouldn’t it be nice to not worry about all that?

A cross-browser test platform in the cloud, like SauceLabs or BrowserStack, can help with those worries. In my case a Browserstack license was available, so that choice was easily made. This article covers the integration of Robot Framework with Browserstack, how to switch between test setups, and some tricks I learned on the way.

Start a browser locally

When the keyword Open Browser is called, the SeleniumLibrary will look for a WebDriver to start the browser with. The WebDriver should be situated in the path environment variable, but I keep forgetting the location to put the WebDriver in.

TRICK: The WebDriverManager helps me to easily manage my local WebDrivers. In the example below I install the WebDriverManager and download the ChromeDriver. With -- linkpath AUTO it will automatically put the driver in the location so SeleniumLibrary will find it. More command line options, check out this page.

pip install webdrivermanager
webdrivermanager chrome --linkpath AUTO 

Start a browser in the Browserstack cloud

Can Open Browser also be used to integrate with Browserstack? Yes! I only have to pass the required parameters, which are defined in the variables below.

These variables are structured within the remote url and desired capabilities, then passed as arguments in the Open Browser keyword.

When I log into my Browserstack account I see the test run with a screen recording, awesome!

Start with a clean slate…

… in order to retrieve independent test results. I start every automated GUI test with a browser, remove cookies and close the browser when it’s finished. With Robot Framework this is possible by using aTest Setup and Test Teardown in the ‘ Settings’ section of the test case file. A setup or teardown always consists of a single keyword. I implement these keywords in my GlobalKeywords file because I use these in all my test cases.

TRICK: Use Suite Setup or Suite Teardown if you want to execute actions before/after a whole file of test cases. Setting the Selenium speed for example.

Switch between test setups

Now I have two test setups; one to test local, and one to test via Browserstack. I don’t want to spend my precious Browserstack Automate minutes on creating and maintaining automated tests, so I want to keep the two setups. And I want to easily switch between test setups per test case file.

That’s why I create a global variable environmentToRunTest and check the value in a generic test setup. In that way I refer to the testSetup in every test setup and I only have to set the preferred environment in one place.

Often I make the mistake to check in the change to remote when I set the environmentToRunTest to LOCAL. When the test runs via a build server, it obviously fails. Luckily there is a way to set variables via the command line!

TRICK: Set the ‘environmentToRunTest’ variable via command line options when running the test. This overwrites the value of the variable in the code and makes the setup foolproof.

robot --variable environmentToRunTest=BROWSERSTACK RainbowCake.feature.robot

Now I can run my tests locally and via Browserstack, what a piece of cake! However, integrating Robot Framework tests behind the proxy with Browserstack, is a whole other story. Stay tuned to find out why and what to do…