Test Automation on Testing Observation

Automatically Specifying Referenceable Fixtures in Pytest

Tue, 24 Sep 2024 13:16:16 +0800

When we use the Pytest framework for Test Automation, its powerful fixtures bring great convenience to the flexible application of the framework. For example, we can use the autouse attribute of a fixture to make it take effect automatically at different scope levels of test methods. But if we want to reference the return value of a fixture, we usually still have to specify it explicitly, which is a bit inconvenient

Specifying a Fixture with autouse, but It Still Needs to Be Explicitly Carried as a Parameter to Be Called

Take webdriver, the most commonly used object in Selenium automation, as an example. When implementing automation, the webdriver object usually stays in effect throughout the entire execution and is frequently called.

The usual practice is to write a session-level generic driver fixture in the conftest.py file and set autouse to enabled:

conftest.py

1
2
3
4
5
6
7


@pytest.fixture(scope="session",autouse=True)
def driver():
 option = webdriver.ChromeOptions()
 driver = webdriver.Chrome(options=option)
 driver.implicitly_wait(3)
 driver = webdriver.Chrome()
 yield driver

Then in another test file, when writing the test class and test methods, we can directly reference this driver fixture

test_auto_driver.py

1
2
3
4


class TestDriver:
 def Test_open_blog(self, driver):
 driver.get("https://chengxiaqiucao.github.io/")
 assert driver.title == "秋 草 观 “测” 台"

But if the whole test project is fairly large and there are many similar test classes and test methods, every time we define a test method we have to specify this generic fixture in order to reference the driver object. Doesn’t that always feel a little inelegant?

Pytest Built-in Fixture: Request

Actually, if you have studied how to do parameterization through fixtures, you should know that parameterization via fixtures is accomplished through an internal fixture of pytest called request. request should be the most important built-in fixture in pytest. And by using this fixture, we can in fact implicitly pass some generic fixtures to each test class by default

A Brief Introduction to request

According to the official documentation:

request is a built-in fixture used to provide contextual information about the current test method and to implement parameterization through the param parameter.

With request, we can obtain a great deal of contextual information about the current fixture during runtime, such as the fixture name, path, the current session, module, class information, and so on.

The figure below shows the attributes of the request object obtained at a breakpoint when referencing a fixture

So in the example above, as a generic fixture that takes effect at the session level, we can use its session attribute to obtain all the classes in the current session, and then assign the driver object to the relevant class attributes. In this way, when defining a test class, we no longer need to specify the fixture separately and can reference it directly through the class attribute as needed.

Implementing Automatic Assignment of a Fixture to Class Attributes

So the code of the above example is modified as follows:

conftest.py

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


@pytest.fixture(scope="session",autouse=True)
def driver(request):
 """
 Automatically apply the fixture and set it as a class attribute of the caller
 :param request: pytest's built-in fixture, used to obtain the fixture's context
 :return:
 """ driver = webdriver.Chrome()
 try:
 session = request.node
 for item in session.items:
 cls = item.getparent(pytest.Class)
 setattr(cls.obj, 'driver', driver)
 yield
 finally:
 driver.quit()

Here we add the driver object as a class attribute, and the fixture itself no longer yields any object as a return value

Correspondingly, in the test script we can simply use the class attribute directly via self.driver

test_auto_driver.py

1
2
3
4


class TestDriver:
 def Test_open_blog(self, driver):
 self.driver.get("https://chengxiaqiucao.github.io/")
 assert self.driver.title == "秋 草 观 “测” 台"

The execution result: the test case is likewise completed correctly.

The above~~

Creating a Product Demo with SeleniumBase

Mon, 23 Sep 2024 00:00:00 +0000

Selenium, as the most popular open-source web Test Automation framework today, has been developed for 20 years. It is powerful, and its webdriver protocol has also become a de facto standard in the field of Test Automation. Based on the Selenium framework, many extension frameworks built on top of it have emerged. One example is SeleniumBase, which we introduce in this article.

What Is SeleniumBase?

SeleniumBase is a Python library built on top of the Selenium framework that further enhances scripting. On top of Selenium’s original functionality, it simplifies the way automation scripts are written and invoked, and it is deeply integrated with the pytest framework. Most importantly, it provides a variety of different script modes, including script recording, slowed-down execution, in-run debugging, and the demo feature we are going to introduce in this article.

Although SeleniumBase is very powerful, the underlying implementation logic of the automation still follows the main characteristics of Selenium. So here we will not specifically introduce SeleniumBase’s wrappers for writing automation scripts. But one excellent thing about this library is that, through JS injection, it makes the automation running process more intuitive and easier to demonstrate.

For example, the demo creation we will see below.

Advantages of Completing a Demo Through Automation Scripts

As test engineers, especially with the popularity of agile development nowadays, the end of an iteration usually includes an iteration review and demo session. And as test engineers, a lot of the feature demos within iterations are done by us.

This also includes the fact that, when introducing product features to customers or leaders, explaining the features through actual product operations is essential as well.

But in practice, if we can display in advance the key points that need to be explained while the automated test is executing, the effect is very good, and it can also avoid some accidental misoperations on the spot.

So this feature of SeleniumBase can really play to its strengths here.

The Process of Creating a Product Demo with SeleniumBase

First, take a look at a demo of the open-source update information on my blog site, completed with SeleniumBase

In fact, its principle is fairly simple: through its wrapped BaseCase class, while the corresponding operation steps are being executed, it injects pre-packaged JS to highlight the elements being operated on and give some guidance hints.

The corresponding create_introjs_tour() method in the base class creates the demo tour. It also offers different JS theme choices here, which is very powerful.

Then add_tour_step() adds the steps, and play_tour() executes the steps.

The corresponding demo generation code:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


from seleniumbase import BaseCase
BaseCase.main(__name__, __file__)


class MyTourClass(BaseCase):
 def test_blog_tour(self):
 self.open("https://chengxiaqiucao.github.io/")
 self.wait_for_element('[class="site-logo"]')

 self.set_introjs_colors("#f34565", "#c55409")
 self.create_introjs_tour() #
 self.add_tour_step("Selenium Base制作Demo演示", title="城下秋草的Demo")
 self.add_tour_step("查看热门开源项目", '#main-menu > li:nth-child(6) > a')
 self.play_tour()
 self.highlight_click('#main-menu > li:nth-child(6) > a')
 self.wait_for_element('[class="article-title"]')

 self.create_introjs_tour()
 self.add_tour_step("选择Selenium项目查看", '#seleniumpageselenium-10 > a')
 self.play_tour()
 self.highlight_click('#seleniumpageselenium-10 > a')
 self.ad_block()
 self.wait_for_element('[class="section-title"]')

 self.create_introjs_tour()
 self.add_tour_step("返回主页", '[class="site-logo"]')
 self.play_tour()
 self.highlight_click('[class="site-logo"]')
 self.wait_for_element('[title="搜索"]')

 self.create_introjs_tour()
 self.add_tour_step("3秒停顿后继续...")
 self.add_tour_step("开始下一个演示:")
 self.play_tour(interval=3)

As for the JS injected in the actual demo, we can also export the corresponding JS script through the self.export_tour statement, so that it can be used directly later.

Similarly, there is also its Demo mode, which is actually quite similar to the guided tour mode, except that it more often automatically slows down and highlights the automation execution steps to emphasize the verification points.

The above is my sharing on this cool feature of the SeleniumBase library~

Projects Suitable for Practicing Test Automation

Fri, 20 Sep 2024 15:24:19 +0800

Many friends who are new to test automation have read a lot of tutorials, but are troubled by not having suitable projects to practice with. Here the author would like to share some good practice projects that have been collected.

DemoQA

DemoQA is a practice website specifically designed for practicing web test automation such as Selenium. It covers all kinds of commonly used elements and controls in the process of learning Web automation, allowing a fairly comprehensive study of page handling.

The-internet

The-Internet is also a project aimed at beginners, specifically for test automation practice, and is quite similar to DemoQA. The scenarios can complement each other. Besides using it online, you can also download the source code from its GitHub project and deploy it yourself (based on Ruby).

SauceLab App

SauceLab is a testing service provider, and SauceDemo is a site it provides for test automation practice.

In addition to the Web version, this project also provides a mobile version, my-demo-app, which can be used for practicing Android/IOS application test automation, and can be obtained through SauceLab’s GitHub project.

https://github.com/saucelabs/my-demo-app-android

https://github.com/saucelabs/my-demo-app-ios

Sahi Test

Sahi Test is a project self-built by a testing blogger for test automation practice, containing very rich scenarios.

GURU99 Demo

Demo Guru99 is a collection of multiple projects integrated by the Guru99 website for test automation practice, including insurance, banking, telecommunications, and the Tour project that comes with the traditional test automation tool QTP.

JpetStore

JpetStore is a pet store application provided by mybatis. Project address: https://github.com/mybatis/jpetstore-6

OpenCart

Besides the projects above that are specifically provided for test automation practice, we can also find some more fully featured open source free sites to use when practicing.

For example, OpenCart is an open source e-commerce website, and you can practice based on its Demo site.

OrangeHRM

OrangeHRM is a powerful open source HR management system, and it is likewise a very good choice as a practice site for test automation.

The above are some commonly used websites collected and organized by the author that can be used for test automation practice. Of course, there are in fact a large number of fairly mature web applications on open source sites, and we can absolutely set them up locally before practicing. If you have any other good practice projects to recommend, feel free to add them in the comments~~

Detailed Guide to Using Selenium Manager

Sat, 07 Sep 2024 18:03:04 +0800

Selenium was born in 2004. With its open source nature and comprehensive features, it has long ranked Top1 in the field of Web test automation tools, and is currently the most mainstream Web test automation tool. Moreover, Selenium’s core Webdriver serves as the prevailing W3C standard and is widely referenced by various tools. It can be said to be the de facto standard for web test automation today.

Changes Brought by Selenium 4

After years of evolution, Selenium itself has now been released up to version V4.24. Although usages and materials related to the V3 version are still widely circulated online, Selenium 4 is actually a very major update. Several of its core components have undergone extensive refactoring.

WebDriver switched from the original Json Wire Protocol to the W3C standard definition
Selenium IDE completed its refactoring and feature optimization
Selenium Grid completed its refactoring and supports a more flexible cloud service architecture

In addition, Selenium 4 introduced a very important tool, which is the Selenium Manager we are going to focus on in this article (it was actually introduced only in V4.6, and its features were basically complete only by V4.12

Problems Caused by the Original Browser Driver Approach

To understand Selenium Manager, we still need to first understand how Selenium works.

How Selenium Works

The figure below is the basic architecture of Selenium’s local execution given on the official site.

As can be seen, Selenium actually accomplishes automation by driving different types of browsers (Chrome, Firefox, IE, Edge, Safari, etc.) through the webdriver protocol to complete specified actions, thereby achieving the goal of automated execution.

The key to driving a browser is the browser Driver that corresponds to the browser, such as ChromeDriver for Chrome, GecoDriver for FireFox, and so on.

And Selenium itself interacts with the browser Driver based on the WebDriver protocol.

The Problems It Causes

Although this architecture and working principle are clear, there is one problem: browser versions are constantly being updated. And the browser driver version needs to match the browser version; when mismatched driver and browser versions work together, various unexpected exceptions may occur. Therefore, for Selenium to work properly, before writing code with the Selenium library, the first thing is to ensure the deployment and matching of the browser driver and browser versions.

But browser versions and their corresponding drivers are usually maintained by the browser vendors.

So preparing the test automation environment here becomes rather complicated: you need to install the browser of the corresponding version under test, and at the same time find the driver corresponding to that version, then configure the relevant paths for Selenium, and only then can Selenium complete normal driving.

In addition, browser versions generally also have an auto-update feature. It may happen that, without the user noticing, the version has already changed, but at that time the driver version is not updated synchronously, so this also leads to the potential problem of driver and browser version mismatch.

This problem was actually not well resolved for a long time. With Selenium 3 and the early versions of Selenium 4, when we deployed a Selenium automation environment, obtaining and matching browser versions and driver versions was always a rather troublesome task, and because of this it discouraged quite a few test automation beginners.

Chrome’s Response to the Driver Problem

Since this problem has existed for a long time, browser vendors have also actually realized the troubles that a mismatch between driver and browser versions brings to test automation.

Taking Chrome as an example, if we go to the official ChromeDriver downloads page, we will see a page like this

As can be seen, Chrome Driver downloads here are only provided up to version 114, while the latest Chrome has actually already reached version 128. For versions after 115, the Chrome browser actually adjusted the driver release strategy, that is, Chrome driver is released in sync with the Chrome for Testing version, strictly ensuring the synchronous matching of driver and browser versions.

So why is there a Chrome for Testing version here?

As we mentioned earlier, browser versions have auto-update; if an auto-update happens, the driver version is not updated synchronously, thus causing a mismatch between driver and browser.

So the main difference between Chrome for Testing and the official version is actually that the for Testing version does not perform auto-updates.

In this way, together with the sharing of version numbers with the browser version, it is very convenient to ensure consistency between the browser and the driver.

Selenium’s Solution to the Driver Matching Problem

The above is the solution given by browsers to the driver matching problem, but it still does not completely solve the problem that the browser and Driver need to be obtained and specified separately. So Selenium’s official solution to this problem is Selenium Manager. It is actually an executable program included in the Selenium library, requiring no additional installation.

If we currently use Selenium V4 to execute a simple test automation script:

For example, to search for the Chinese phrase 城下秋草测试 on Baidu, the code is as follows:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


from selenium import webdriver
from selenium.webdriver.common.by import By
from time import sleep

def test_baidu_search():
 option = webdriver.ChromeOptions()
 option.browser_version = '117'
 driver = webdriver.Chrome(options=option)

 driver.get("https://www.baidu.com")
 driver.find_element(By.ID,'kw').send_keys('城下秋草 测试')
 sleep(2)
 driver.find_element(By.ID,'su').click()
 sleep(3)
 driver.close()

As long as the Selenium library is installed, when executing, it can drive normally, without any special need to obtain the driver and configuration.

Source Code Analysis of Selenium 4 Launching Automation Execution

Here we analyze its startup process from Selenium’s Python source code:

driver = webdriver.Chrome(options=option)

This line of code actually calls the webdriver initialization code for the Chromium-based browser in the Selenium library, located at .venv/Lib/site-packages/selenium/webdriver/chromium/webdriver.py

During initialization, as can be seen, the DriverFinder method is used to obtain the paths of the browser and the Driver

1
2
3
4
5
6
7


finder = DriverFinder(self.service, options)
if finder.get_browser_path():
 options.binary_location = finder.get_browser_path()
 options.browser_version = None

self.service.path = finder.get_driver_path()
self.service.start()

And the method for obtaining the paths actually calls the binary_paths method of the SeleniumManager module

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


def get_browser_path(self) -> str:
 return self._binary_paths()["browser_path"]

def get_driver_path(self) -> str:
 return self._binary_paths()["driver_path"]

def _binary_paths(self) -> dict:
 if self._paths["driver_path"]:
 return self._paths

.
.
.


 output = SeleniumManager().binary_paths(self._to_args())
.
.
.
 return self._paths

The SeleniumManager module, in turn, executes the SeleniumManager binary program and, based on the relevant parameters, obtains the browser and driver versions.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


def _run(args: List[str]) -> dict:
 """Executes the Selenium Manager Binary.

 :Args: - args: the components of the command being executed. :Returns: The log string containing the driver location. """ command = " ".join(args)
 logger.debug("Executing process: %s", command)
 try:
 if sys.platform == "win32":
 completed_proc = subprocess.run(args, capture_output=True, creationflags=subprocess.CREATE_NO_WINDOW)
 else:
 completed_proc = subprocess.run(args, capture_output=True)
 stdout = completed_proc.stdout.decode("utf-8").rstrip("\n")
 stderr = completed_proc.stderr.decode("utf-8").rstrip("\n")
 output = json.loads(stdout) if stdout != "" else {"logs": [], "result": {}}
 except Exception as err:
 raise WebDriverException(f"Unsuccessful command executed: {command}") from err

 SeleniumManager._process_logs(output["logs"])
 result = output["result"]
 if completed_proc.returncode:
 raise WebDriverException(
 f"Unsuccessful command executed: {command}; code: {completed_proc.returncode}\n{result}\n{stderr}"
 )
 return result

Therefore, when the current Selenium 4 version executes, it uses the SeleniumManager program to determine the required browser and corresponding driver version.

The Selenium Manager Command-Line Program

Through SeleniumManager, based on the browser type and version we configure, it can automatically match the relevant driver version, and connect to the network on its own to obtain the files of the relevant driver and browser version for Selenium to call. For example, in the case above, we specified the browser version as 117; after execution, the downloaded browser and corresponding driver version are actually saved in the .cache\selenium directory under the user directory. The figure below shows the driver of version 117 currently updated by the execution.

What Selenium calls here is the Selenium-manager command-line program

We can directly execute this program and add --help to see the supported parameters

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60


selenium-manager 0.4.24
Selenium Manager is a CLI tool that automatically manages the browser/driver infrastructure required by Selenium.


Usage: selenium-manager [OPTIONS]
Options:
 --browser <BROWSER>
 Browser name (chrome, firefox, edge, iexplorer, safari, safaritp, or webview2)
 --driver <DRIVER>
 Driver name (chromedriver, geckodriver, msedgedriver, IEDriverServer, or safaridriver)
 --grid [<GRID_VERSION>]
 Selenium Grid. If version is not provided, the latest version is downloaded
 --driver-version <DRIVER_VERSION>
 Driver version (e.g., 106.0.5249.61, 0.31.0, etc.)
 --browser-version <BROWSER_VERSION>
 Major browser version (e.g., 105, 106, etc. Also: beta, dev, canary -or nightly-, and esr -in Firefox- are accepted)
 --browser-path <BROWSER_PATH>
 Browser path (absolute) for browser version detection (e.g., /usr/bin/google-chrome, "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome", "C:\Program Files\Google\Chrome\Application\chrome.exe")
 --driver-mirror-url <DRIVER_MIRROR_URL>
 Mirror for driver repositories (e.g., https://registry.npmmirror.com/-/binary/chromedriver/)
 --browser-mirror-url <BROWSER_MIRROR_URL>
 Mirror for browser repositories
 --output <OUTPUT>
 Output type: LOGGER (using INFO, WARN, etc.), JSON (custom JSON notation), SHELL (Unix-like), or MIXED (INFO, WARN, DEBUG, etc. to stderr and minimal JSON to stdout) [default: LOGGER]
 --os <OS>
 Operating system (i.e., windows, linux, or macos)
 --arch <ARCH>
 System architecture (i.e., x32, x64, or arm64)
 --proxy <PROXY>
 HTTP proxy for network connection (e.g., https://myproxy.net:8080)
 --timeout <TIMEOUT>
 Timeout for network requests (in seconds) [default: 300]
 --ttl <TTL>
 TTL (time-to-live) for discovered versions (online) of drivers and browsers [default: 3600]
 --cache-path <CACHE_PATH>
 Local folder used to store downloaded assets (drivers and browsers), local metadata, and configuration file [default: ~/.cache/selenium]
 --clear-cache
 Clear cache folder (~/.cache/selenium)
 --clear-metadata
 Clear metadata file (~/.cache/selenium/selenium-manager.json)
 --debug
 Display DEBUG messages
 --trace
 Display TRACE messages
 --log-level <LOG_LEVEL>
 Level for output messages. The possible values are: info, debug, trace, warn, error
 --offline
 Offline mode (i.e., disabling network requests and downloads)
 --force-browser-download
 Force to download browser (even when browser is already in the system)
 --avoid-browser-download
 Avoid to download browser (even when browser-version is specified)
 --language-binding <LANGUAGE_BINDING>
 Selenium language bindings that invokes Selenium Manager (e.g., Java, JavaScript, Python, DotNet, Ruby)
 --avoid-stats
 Avoid sends usage statistics to plausible.io
 -h, --help
 Print help
 -V, --version
 Print version

We can execute it to take a look at the output information here; actually, when selenium executes, it is precisely this command-line program that it calls

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41


>selenium-manager.exe --browser firefox --debug # the debug parameter shows detailed output

[2024-09-10T13:35:56.007Z DEBUG] geckodriver not found in PATH

# First, determine whether a driver exists in the system PATH based on the specified browser

[2024-09-10T13:35:56.010Z DEBUG] firefox not found in PATH

# Likewise, based on whether the PATH contains the firefox browser installation path

[2024-09-10T13:35:56.010Z DEBUG] Running command: REG QUERY HKCU\Software\Mozilla\Mozilla Firefox /v CurrentVersion
[2024-09-10T13:35:56.034Z DEBUG] Output: ""
[2024-09-10T13:35:56.036Z DEBUG] firefox not found in the system

# Find the firefox browser installation path through the registry

[2024-09-10T13:35:56.037Z DEBUG] Required browser: firefox 130.0

-- No browser version specified; obtain the latest version based on online information

[2024-09-10T13:35:56.037Z DEBUG] Downloading firefox 130.0 from https://ftp.mozilla.org/pub/firefox/releases/130.0/win64/en-US/Firefox%20Setup%20130.0.exe

# Download from the official site

[2024-09-10T13:36:13.320Z DEBUG] firefox 130.0 is available at C:\Users\Administrator\.cache\selenium\firefox\win64\130.0\firefox.exe

# Download complete

[2024-09-10T13:36:14.367Z DEBUG] Valid geckodriver versions for firefox 130: ["0.35.0", "0.34.0"]

# Get available driver versions

[2024-09-10T13:36:14.369Z DEBUG] Required driver: geckodriver 0.35.0
[2024-09-10T13:36:14.372Z DEBUG] Downloading geckodriver 0.35.0 from https://github.com/mozilla/geckodriver/releases/download/v0.35.0/geckodriver-v0.35.0-win64.zip

# Download the corresponding driver

[2024-09-10T13:36:18.238Z INFO ] Driver path: C:\Users\Administrator\.cache\selenium\geckodriver\win64\0.35.0\geckodriver.exe
[2024-09-10T13:36:18.239Z INFO ] Browser path: C:\Users\Administrator\.cache\selenium\firefox\win64\130.0\firefox.exe

# Output the browser and driver paths; this is actually the information returned when selenium calls it

And besides Browser and Driver, Selenium-manager actually also supports downloading grid versions. Through the --grid parameter, the latest version of grid can be downloaded directly.

1
2
3
4
5
6


> selenium-manager.exe --grid --debug
[2024-09-10T13:47:41.793Z DEBUG] Sending stats to Plausible: Props { browser: "grid", browser_version: "", os: "windows", arch: "amd64", lang: "", selenium_version: "4.24" }
[2024-09-10T13:47:41.795Z DEBUG] grid not found in the system
[2024-09-10T13:47:43.667Z DEBUG] Required driver: selenium-server 4.24.0
[2024-09-10T13:47:43.669Z DEBUG] Downloading selenium-server 4.24.0 from https://github.com/SeleniumHQ/selenium/releases/download/selenium-4.24.0/selenium-server-4.24.0.jar
[2024-09-10T13:47:51.547Z INFO ] Driver path: C:\Users\Administrator\.cache\selenium\grid\4.24.0\selenium-server-4.24.0.jar

From the introduction above, it can be seen that by introducing Selenium-manager, Selenium can now, during environment preparation, very flexibly achieve automatic acquisition and configuration of resources such as the browser, the driver, and even the grid server, greatly improving the convenience of using Selenium.

Fixture Scope in Pytest

Wed, 28 Aug 2024 20:33:52 +0800

pytest, as the most mainstream testing framework in the Python technology stack, is extremely powerful and flexible. Fixtures are at its core. Moreover, pytest also distinguishes different scopes for fixtures, which brings great flexibility to how we use them.

Let us take a look below at the role of each different scope.

Definition of fixture scope

First, according to the official documentation, the scope of a fixture in Pytest supports five settings: function (the default), classs, module, package, and session

Scope	Description
function	Default value; takes effect for each test method (function), with a lifecycle at the test method level
class	Takes effect for the test class, with a lifecycle at the test class level
module	Takes effect for the test module, with a lifecycle at the module (file) level
package	Takes effect for the test package, with a lifecycle at the test package (directory) level
session	Takes effect for the test session, with a lifecycle at the session (one pytest run) level

Let us illustrate this with code below. Suppose we currently have the following code structure

run_params is the method under test

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


def deal_params(p):
 print(f"input :{p}")
 if type(p) is int:
 return p*10
 if type(p) is str:
 return p*3
 if type(p) in (tuple, list):
 return "_".join(p)
 else:
 raise TypeError

test_ch_param and test_fixture_scope respectively define parameterization and the different test methods inside a test class

1
2
3
4
5


import pytest

@pytest.mark.parametrize("param",[10, "城下秋草", "软件测试", ("示例", "代码")])
def test_params_mark(param):
 print(deal_params(param))

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


import pytest

class TestFixtureScope1:
 def test_int(self):
 assert deal_params(2) == 20

 def test_str(self):
 assert deal_params("秋草") == "秋草秋草秋草"

class TestFixtureScope2:
 def test_list(self):
 assert deal_params(["城下","秋草"]) == "城下_秋草"

 def test_dict(self):
 with pytest.raises(TypeError):
 deal_params({"name": "秋草"})

In the common method file conftest.py, define the fixture prepare and set autouse=True, which means it will be applied automatically according to the configured scope of the fixture

1
2
3
4
5


@pytest.fixture(autouse=True, scope='function')
def prepare():
 print('-----some setup actions.....')
 yield
 print('-----some teardown actions!!')

Here we set the scope of prepare to different values respectively, and then obtain the corresponding outputs

function

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43


(.venv) C:\Chengxiaqiucao
pytest
======================================== test session starts =========================================
collected 8 items

BlogDemo/testDemo/test_ch_parm.py::test_params_mark[10] -----some setup actions.....
input :10
100
PASSED-----some teardown actions!!

BlogDemo/testDemo/test_ch_parm.py::test_params_mark[城下秋草] -----some setup actions.....
input :城下秋草
城下秋草城下秋草城下秋草
PASSED-----some teardown actions!!

BlogDemo/testDemo/test_ch_parm.py::test_params_mark[软件测试] -----some setup actions.....
input :软件测试
软件测试软件测试软件测试
PASSED-----some teardown actions!!

BlogDemo/testDemo/test_ch_parm.py::test_params_mark[param3] -----some setup actions.....
input :('示例', '代码')
示例_代码
PASSED-----some teardown actions!!

BlogDemo/testDemo/test_fixture_scope.py::TestFixtureScope1::test_int -----some setup actions.....
input :2
PASSED-----some teardown actions!!

BlogDemo/testDemo/test_fixture_scope.py::TestFixtureScope1::test_str -----some setup actions.....
input :秋草
PASSED-----some teardown actions!!

BlogDemo/testDemo/test_fixture_scope.py::TestFixtureScope2::test_list -----some setup actions.....
input :['城下', '秋草']
PASSED-----some teardown actions!!

BlogDemo/testDemo/test_fixture_scope.py::TestFixtureScope2::test_dict -----some setup actions.....
input :{'name': '秋草'}
PASSED-----some teardown actions!!


========================================= 8 passed in 0.27s ==========================================

The fixture ran 8 times

class

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


(.venv) C:\Chengxiaqiucao
pytest
======================================== test session starts =========================================
collected 8 items

BlogDemo/testDemo/test_ch_parm.py::test_params_mark[10] -----some setup actions.....
input :10
100
PASSED-----some teardown actions!!

BlogDemo/testDemo/test_ch_parm.py::test_params_mark[城下秋草] -----some setup actions.....
input :城下秋草
城下秋草城下秋草城下秋草
PASSED-----some teardown actions!!

BlogDemo/testDemo/test_ch_parm.py::test_params_mark[软件测试] -----some setup actions.....
input :软件测试
软件测试软件测试软件测试
PASSED-----some teardown actions!!

BlogDemo/testDemo/test_ch_parm.py::test_params_mark[param3] -----some setup actions.....
input :('示例', '代码')
示例_代码
PASSED-----some teardown actions!!

BlogDemo/testDemo/test_fixture_scope.py::TestFixtureScope1::test_int -----some setup actions.....
input :2
PASSED
BlogDemo/testDemo/test_fixture_scope.py::TestFixtureScope1::test_str input :秋草
PASSED-----some teardown actions!!

BlogDemo/testDemo/test_fixture_scope.py::TestFixtureScope2::test_list -----some setup actions.....
input :['城下', '秋草']
PASSED
BlogDemo/testDemo/test_fixture_scope.py::TestFixtureScope2::test_dict input :{'name': '秋草'}
PASSED-----some teardown actions!!


========================================= 8 passed in 0.27s ==========================================

The test methods in test_ch_param, because they are defined directly in the file, also belong to the class level, so the fixture is also called each time a parameter is assigned. In test_fixture_scope, two test classes are explicitly defined, so it ran 2 times

module

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


(.venv) C:\Chengxiaqiucao
pytest
======================================== test session starts =========================================
collected 8 items

BlogDemo/testDemo/test_ch_parm.py::test_params_mark[10] -----some setup actions.....
input :10
100
PASSED
BlogDemo/testDemo/test_ch_parm.py::test_params_mark[城下秋草] input :城下秋草
城下秋草城下秋草城下秋草
PASSED
BlogDemo/testDemo/test_ch_parm.py::test_params_mark[软件测试] input :软件测试
软件测试软件测试软件测试
PASSED
BlogDemo/testDemo/test_ch_parm.py::test_params_mark[param3] input :('示例', '代码')
示例_代码
PASSED-----some teardown actions!!

BlogDemo/testDemo/test_fixture_scope.py::TestFixtureScope1::test_int -----some setup actions.....
input :2
PASSED
BlogDemo/testDemo/test_fixture_scope.py::TestFixtureScope1::test_str input :秋草
PASSED
BlogDemo/testDemo/test_fixture_scope.py::TestFixtureScope2::test_list input :['城下', '秋草']
PASSED
BlogDemo/testDemo/test_fixture_scope.py::TestFixtureScope2::test_dict input :{'name': '秋草'}
PASSED-----some teardown actions!!


========================================= 8 passed in 0.27s ==========================================

After changing to the module scope, we can see that the fixture is called once for each module file

package

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


(.venv) C:\Chengxiaqiucao
pytest
======================================== test session starts =========================================
collected 8 items

BlogDemo/testDemo/test_ch_parm.py::test_params_mark[10] -----some setup actions.....
input :10
100
PASSED
BlogDemo/testDemo/test_ch_parm.py::test_params_mark[城下秋草] input :城下秋草
城下秋草城下秋草城下秋草
PASSED
BlogDemo/testDemo/test_ch_parm.py::test_params_mark[软件测试] input :软件测试
软件测试软件测试软件测试
PASSED
BlogDemo/testDemo/test_ch_parm.py::test_params_mark[param3] input :('示例', '代码')
示例_代码
PASSED
BlogDemo/testDemo/test_fixture_scope.py::TestFixtureScope1::test_int input :2
PASSED
BlogDemo/testDemo/test_fixture_scope.py::TestFixtureScope1::test_str input :秋草
PASSED
BlogDemo/testDemo/test_fixture_scope.py::TestFixtureScope2::test_list input :['城下', '秋草']
PASSED
BlogDemo/testDemo/test_fixture_scope.py::TestFixtureScope2::test_dict input :{'name': '秋草'}
PASSED-----some teardown actions!!


========================================= 8 passed in 0.27s ==========================================

After changing to package, this is because the two test files are located in the same package, so it ran once

session

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


(.venv) C:\Chengxiaqiucao
pytest
======================================== test session starts =========================================
collected 8 items

BlogDemo/testDemo/test_ch_parm.py::test_params_mark[10] -----some setup actions.....
input :10
100
PASSED
BlogDemo/testDemo/test_ch_parm.py::test_params_mark[城下秋草] input :城下秋草
城下秋草城下秋草城下秋草
PASSED
BlogDemo/testDemo/test_ch_parm.py::test_params_mark[软件测试] input :软件测试
软件测试软件测试软件测试
PASSED
BlogDemo/testDemo/test_ch_parm.py::test_params_mark[param3] input :('示例', '代码')
示例_代码
PASSED
BlogDemo/testDemo/test_fixture_scope.py::TestFixtureScope1::test_int input :2
PASSED
BlogDemo/testDemo/test_fixture_scope.py::TestFixtureScope1::test_str input :秋草
PASSED
BlogDemo/testDemo/test_fixture_scope.py::TestFixtureScope2::test_list input :['城下', '秋草']
PASSED
BlogDemo/testDemo/test_fixture_scope.py::TestFixtureScope2::test_dict input :{'name': '秋草'}
PASSED-----some teardown actions!!


========================================= 8 passed in 0.27s ==========================================

Finally, when set to session — that is, one execution session of running pytest — only then is a single fixture call triggered

So we can see that by defining different scopes for fixtures, we can determine the scope of the fixtures we write according to our needs, which offers great flexibility

Flexible Scope Definition for Complex Fixtures

Sometimes in actual use — especially when the initialization work of some of our fixtures is fairly complex but may be needed at different scopes at the same time — if we had to write several different fixtures merely because of the different scopes, the code would become rather redundant. How can we handle this? In fact, we can implement it flexibly using the contextmanager context.

For example, let us write another basic code context for a fixture:

1
2
3
4
5


@contextmanager
def fixture_base():
 print('~~~~~base fixture setup actions.....')
 yield
 print('~~~~~base fixture teardown actions!!')

Then for different fixtures, we can define different fixtures according to different scopes and call the context implementation here. For example, let us define another fixture with the scope set to package

1
2
3
4
5
6
7


@pytest.fixture(autouse=False, scope='package')
def fixture_module():
 """
 For complex fixtures where you want flexible scope handling, you can put the common code into a contextmanager,
 and then define corresponding fixtures for different scopes
 """ with fixture_base() as result:
 yield result

👍👍This method comes from a summary by the pytest community, original issue link

Execution Order of Different Scopes

In the example above we actually saw the execution effect of package and session; because the test methods are all in the same package, there is no difference in effect. But in fact, different scopes also have an execution order

The order is summarized as follows:

session > package > module > class > function

After adding up to two fixtures here, the execution result is:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


(.venv) C:\Chengxiaqiucao
pytest
======================================== test session starts =========================================
collected 8 items

BlogDemo/testDemo/test_ch_parm.py::test_params_mark[10] -----some setup actions.....
~~~~~base fixture setup actions.....
input :10
100
PASSED
BlogDemo/testDemo/test_ch_parm.py::test_params_mark[城下秋草] input :城下秋草
城下秋草城下秋草城下秋草
PASSED
BlogDemo/testDemo/test_ch_parm.py::test_params_mark[软件测试] input :软件测试
软件测试软件测试软件测试
PASSED
BlogDemo/testDemo/test_ch_parm.py::test_params_mark[param3] input :('示例', '代码')
示例_代码
PASSED
BlogDemo/testDemo/test_fixture_scope.py::TestFixtureScope1::test_int input :2
PASSED
BlogDemo/testDemo/test_fixture_scope.py::TestFixtureScope1::test_str input :秋草
PASSED
BlogDemo/testDemo/test_fixture_scope.py::TestFixtureScope2::test_list input :['城下', '秋草']
PASSED
BlogDemo/testDemo/test_fixture_scope.py::TestFixtureScope2::test_dict input :{'name': '秋草'}
PASSED~~~~~base fixture teardown actions!!
-----some teardown actions!!


========================================= 8 passed in 0.27s ==========================================

We can see that session is executed earlier than package and is also torn down later.

So the above is the summary of pytest scope.

Let me also promote my testing course. Those who are interested can learn more through the link below~

❤️❤️❤️❤️ Chengxiaqiucao’s Test Career Advancement Course ❤️❤️❤️❤️

Parameterization with Pytest Fixtures and the Garbled Chinese Text Problem

Sat, 24 Aug 2024 00:11:46 +0800

As we know, Pytest is the mainstream testing framework for Test Automation in the Python technology stack. It supports flexible test discovery and execution strategies, powerful fixtures, and a rich ecosystem of plugins.

Besides parameterization via pytest’s parametrize marker, we can also conveniently implement parameterized testing through the param parameter of a fixture

Implementing Parameterization with Fixtures

Suppose we have the following code under test, which produces different output depending on the type of the parameter passed in

1
2
3
4
5
6
7
8
9


def deal_params(p):
 if type(p) is int:
 return p*10
 if type(p) is str:
 return f"输入了:{p}"
 if type(p) in (tuple, list):
 return "_".join(p)
 else:
 raise TypeError

Then we write the corresponding test code: first we define a fixture and set the params list, then obtain each param through the fixture’s own request. For example, here we define several parameters. The Chinese strings in the example below are example parameter values. In addition, we also define the fixture’s setup and teardown actions. The test method simply calls the function under test.

1
2
3
4
5
6


@pytest.fixture(params=[10, "城下秋草", "软件测试", ("示例", "代码")])
def fix_env(request):
 yield request.param

def test_params(fix_env):
 print(deal_params(fix_env))

Running it produces the following output: As you can see, although parameterization ran successfully, there is a problem here: in the output, the test case ID is displayed as garbled text. According to pytest’s ID generation rules, if it is a string or a number, the parameter itself that was passed in is displayed (of course you can also use the ids parameter to reassign the corresponding ID of a parameter); if it is a tuple, list, or dict, it displays the fixture’s name plus the parameter index, such as fix_env3 here

Here the characters are Chinese, shown as the encoding before unicode escaping, so there is still a problem with the Chinese conversion. That is to say, Pytest’s handling of fixture parameters uses ASCII encoding for display by default, whereas for Chinese we want it displayed with unicode encoding.

Solution One for Garbled Chinese Text

Therefore, the first way to solve this problem here is to use Pytest’s centralized fixture configuration file conftest.py, and within it use Pytest’s hook mechanism to modify the part of the test case collection method that generates the test case IDs. The corresponding code:

Defined in conftest.py at the same level as the test case file:

1
2
3
4
5


def pytest_collection_modifyitems(items):
 # item is a collected test case; re-encode it
 for item in items:
 item.name = item.name.encode("utf-8").decode("unicode-escape")
 item._nodeid = item._nodeid.encode("utf-8").decode("unicode-escape")

Run it again and you can see that Chinese is now displayed correctly

Solution Two for Garbled Chinese Text

Besides modifying the hook to re-encode the test case IDs, Pytest itself actually also provides a configuration parameter. It is just that this configuration is not the officially recommended solution. Under certain circumstances on some operating systems, using this configuration may cause some unusual bugs. But the author has tested it on Windows and Ubuntu without any problems.

The corresponding configuration is:

1

disable_test_id_escaping_and_forfeit_all_rights_to_community_support = True

As you can tell from this extremely long configuration name, it disables test ID escaping while forfeiting community support 😂😂

Adding this configuration in pytest.ini, without using the hook above, also gives the effect of Chinese displaying correctly.

The above are the solutions to the garbled text problem you may encounter when Chinese is displayed during parameterization in Pytest.

My Test Career Advancement Course is currently being actively promoted on IMOOC; if you’re interested, you can learn more through the link below

❤️❤️❤️❤️ Chengxia Qiucao’s Test Career Advancement Course ❤️❤️❤️❤️