Pytest 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~~

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 ❤️❤️❤️❤️