There are various reasons for running Python browser automation tests locally, the most common one for us is saving time. Loadero test runs usually take no more than 5 minutes to initialize and start execution but can reach up to 10 minutes or more depending on how busy is the test run queue. To increase the speed of development, it’s often quicker to create the test script on your local machine and then run tests on Loadero. Loadero’s test initialization time is unavoidable if you want to use one of its key features – multiple test participants (not just a few, but up to tens of thousands ). If you limit your tests to just one participant to make a quick run for checking your progress, the test can be run on your local machine, avoiding waiting times. There you can quickly develop a working script that can be run on Loadero with thousands of concurrent participants later. This blog post will show you how to set up a local test script development environment in Python for a single test participant. If you plan to do the same with Javascript, you might find this blog post about test automation with Javascript and Nightwatch framework handy.
To fully set up the script development environment, we must set up the following 2 environments:
Python environment
The first thing you need to prepare to work on your local tests is the Python environment. In a directory of your choice create a virtual environment with
python -m venv py-script-dev-env
then activate the environment on macOS and Linux with
source py-script-dev-env/bin/activate
and on Windows with
py-script-dev-env\Scripts\activate.bat
Creating a virtual environment is not a direct necessity for local script development, but it is always a good idea to separate your Python environments to keep your global installation clean. This is what we usually do when we are working on developing a new test script.
Tip: The Python version used in this blog is 3.10.4, but using any version newer than 3.6 is also fine.
Now, we have to install the Py-TestUI framework which is used by Loadero to automate user actions in the browser.
But before doing that, one of the Py-TestUI dependencies needs to be installed separately – Selenium 4.1.0. This is because at the time of writing this blogpost the latest version of Selenium is 4.1.4, but Py-TestUI hasn’t caught up yet, so an older version of Selenium needs to be installed first. Selenium 4.1.0 is also the version that Loadero currently uses.
pip install selenium==4.1.0
Also, currently, Py-TestUI is not available on PIP (Python Package Index), but we can utilize the pip utility to install it directly from GitHub. As of writing this blog post the latest Py-TestUI version is 1.1.0. To install it run
pip install git+https://github.com/testdevlab/Py-TestUI@v1.1.0
Automation environment
Now let’s set up an automation environment that runs directly on your machine. By default, Selenium looks for a browser driver executable in the default search path. So all we have to do is install the desired browser driver and make sure that the $PATH
environment variable points to it.
Browser driver is an API implementation of the W3C WebDriver standard for a specific browser. Here you can find download links for chromedriver and geckodriver. The installation process will vary between platforms.
For macOS users I suggest installing via brew, both chromedriver and geckodriver are available on it.
brew install chromedriver
brew install geckodriver
Linux users will have to download the compressed driver file from the links provided above. Extract the driver binary with
tar -xf geckodriver-v0.31.0-linux64.tar.gz
or
unzip chromedriver_linux64.zip
Then move the extracted binary into a directory that $PATH
points to. I suggest /usr/local/bin
.
mv geckodriver /usr/local/bin
mv chromedriver /usr/local/bin
Windows users also have to download the archived driver files and extract them with some utility like WinRAR. Then add the binaries to default search path. Then create a folder C:\bin
by running
mkdir C:\bin
Move the driver binaries to C:\bin
Edit the PATH
for your account with
setx PATH "C:\bin;%PATH%"
Finally, restart the command prompt.
To check if driver binaries are on your systems default search path run
chromedriver --version
and
geckodriver --version
Everything is working fine if the command outputs the version string of the driver you installed, that looks something like this for chromedriver
ChromeDriver 100.0.4896.60 (6a5d10861ce8de5fce22564658033b43cb7de047-refs/branch-heads/4896@{#875})
and something like this for geckodriver
geckodriver 0.31.0
The source code of this program is available from
testing/geckodriver in https://hg.mozilla.org/mozilla-central.
This program is subject to the terms of the Mozilla Public License 2.0.
You can obtain a copy of the license at https://mozilla.org/MPL/2.0/.
Everything required for running browser automation scripts in Python is installed. Let’s do a simple test that demonstrates everything working together.
Tip: You can find the basics of test automation explained and some of the commonly used commands described in our previous post about test automation with Python.
Running a test locally
Create a file in the directory that you chose as the parent directory of your environment.
touch simple_test.py
This file will contain your script. Here is a simple example script we’ll use, feel free to copy and paste it to quickly check if everything works correctly.
import time
from testui.support.appium_driver import NewDriver
driver = (
NewDriver()
.set_logger()
.set_browser("chrome")
.set_selenium_driver()
)
driver.navigate_to("https://loadero.com/")
time.sleep(10)
driver.quit()
You can find the script example in Loadero’s Github repository. To run this test, execute the following command
python simple_test.py
A Google Chrome browser window should open and navigate to Loadero’s home page and wait for 10 seconds.
Now you have a working local browser automation Python environment, but to make it feel more like a Loadero test script there are a few more steps ahead.
Using Python browser automation test script
Loadero test scripts are run as pytest fixtures. Luckily Py-TestUI already installed pytest as a dependency, so we can safely import it.
First, let’s create a new Python script that utilizes pytest.
touch test_script.py
import pytest
import time
from testui.support.appium_driver import NewDriver
from testui.support.testui_driver import TestUIDriver
@pytest.fixture(autouse=True)
def driver() -> TestUIDriver:
driver = (
NewDriver()
.set_logger()
.set_browser("chrome")
.set_selenium_driver()
)
print("starting test script execution")
yield driver
print("test script execution finished")
driver.quit()
@pytest.mark.test
def test_on_loadero(driver: TestUIDriver) -> None:
driver.navigate_to("https://loadero.com/")
time.sleep(10)
Here is a brief explanation of what this short script does:
-
@pytest.fixture(autouse=True)
indicates that the function driver will be automatically used for all pytest tests. This makes it a convenient place to set up the PyTestUI driver. -
yield
driver pauses the execution driver function and returns the driver object. After pytest tests finish running, regardless of success or failure driver function execution will resume and the Selenium driver connection will be closed. -
@pytest.mark.test
gives the test_on_loadero function a special marker test that can be later referenced. -
test_on_loadero
contains the test script logic.
Run the script with
pytest loadero_script.py -s -m test
The -s
argument indicates pytest to not capture any input or output of the test. The -m
test tells pytest to run only tests marked with test
. To avoid a pytest warning – PytestUnknownMarkWarning
create a pytest.ini
touch pytest.ini
and predefine the test
marker in that file.
[pytest]
markers =
test: marks function as loadero script
Notice that the function test_on_loadero
name matches the entry point function name in Loadero Python test scripts. Although you can name the function however you want, matching function names were chosen deliberately to showcase that the function provides an entry point for the test script both on the local setup and in Loadero. This means that the script you develop locally can be transported to Loadero by copying the test_on_loadero
function and its helper functions, except the driver
fixture, to a Loadero test script. The script example, its Loadero counterpart, and the pytest configuration file are available on Github.
Now your environment is complete and you can start working on your first automation script. One important thing to notice is that Loadero provides custom variables, constants, and commands for file uploads, custom network conditions, measuring command execution time, and other things available only in Loadero. You can read more about them here. These commands will not be available on your local setup.
This concludes the environment setup and you are ready to develop your Loadero scripts on your quick local setup. Once you are ready to try running the test script with multiple participants, you can do that using Loadero’s free trial. Good luck at the tests, and see you in the next blog.
Top comments (0)