Directory
Unittest vs. Pytest
Use case writing rules
Use case pre- and post-conditions
assertion
testing report
Failure rerun mechanism
to parameterize
Use Case Classification Execution
Example demonstration
front and rear difference
Parametric difference
Summarize
The python unit test framework often uses unittest, because it is relatively basic and can be used for secondary development. If your development level is very high, integrated development of automated test platforms is also possible. Next, we will mainly talk about the difference between unittest and pytest, pytest Compared with unittest, the code is concise, convenient and flexible to use, and the plug-ins are rich.
Unittest vs Pytest
Mainly compare the differences between unittest and pytest from the aspects of use case writing rules, pre and post use cases, parameterization, assertion, use case execution, failure rerun and reporting
Use case writing rules
Use case pre- and post-conditions
pytest automated testing framework: Learn the pytest automated testing framework in 3 days, and you will read it for me when you cry_哔哩哔哩_bilibili
https://www.bilibili.com/video/BV1oX4y1Z7yw/?spm_id_from=333.999.0.0
Assertion
Test report
Failure rerun mechanism
Parameterization
Use case classification execution
If it doesn’t look good, you can see the table below:
unittestpytest
Use case writing method
1) The test file must import the unittest package
2) The test class must inherit unittest.TestCase
3) The test class must have the unittest.main() method
4) The test method must start with test_
1) The test file name should start with test_ or end with _test
2) The name of the test class should start with Test
3) The test method name starts with test_
Use Case Classification Execution
Execute all use cases by default,
You can also execute some use cases by loading the testsuit
Mark classes and methods with the @pytest.mark method,
pytest main adds parameter -m to only execute marked classes and methods
The front and back of the use case provide setUp/tearDown, which can only be used for all use cases. The fixture in pytest is obviously more flexible. The method function can be customized arbitrarily, as long as the decorator @pytest.fixture() is added, the decorated method can be used
Parameterization depends on the ddt library using the @pytest.mark.parametrize decorator
Assertion Format Assertion Many assertion formats (assertEqual, assertIn, assertTrue, assertFalse) only have one expression assert, which is more convenient to use
Generate test reports using HTMLTestRunnerpytest-HTML, allure plugin
Failure rerun without pytest-rerunfailures plugin to support failure rerun
Generally speaking, the format of unittest use cases is complicated, there is no compatibility, there are few plug-ins, and secondary development is convenient. pytest is more convenient and fast, and the use case format is simple. It can execute unittest-style test cases without modifying any code of the unittest use case, and has better compatibility. The pytest plug-in is rich, such as the flask plug-in, which can be used to rerun the use case when an error occurs, and the xdist plug-in, which can be used for parallel execution of the device, which is more efficient.
Example demo
The difference between front and back
Let’s take a look at the difference between pre- and post-use of use cases. Let’s first look at the pre- and post-use of unittest:
import unittest
class TestFixtures01(unittest. TestCase):
# Execute before all use cases are executed
def setUp(self) -> None:
print("setUp starts")
def tearDown(self) -> None:
print("tearDown ends")
# Execute before each use case is executed
@classmethod
def setUpClass(cls) -> None:
print("setUpClass start")
@classmethod
def tearDownClass(cls) -> None:
print("tearDownClass end")
# test case
def test_001(self):
print("Test case 001")
class TestFixtures02(unittest. TestCase):
def test_002(self):
print("Test class 2")
# Execute before each module is executed
def setUpModule():
"""
All test classes will be executed once before they are called. The function name is fixed and will be automatically recognized by the unittest framework.
"""
print('Integration test >>>>>>>>>>>>>>>>Start')
def tearDownModule():
print("Integration test >>>>>>>>>>>>>>>End")
if __name__ == '__main__':
unittest. main()
operation result:
From the results, we know the logical priority of the three methods: setUp() & amp;tearDown() < setUpClass() & amp;tearDownClass() < setUpModule() & amp;tearDownModule()
Next, look at the front and back of pytest:
1. We all know that front and back will be used in automated testing. Compared with unittest, pytest is much more flexible in terms of front and back or plug-ins, and it can also be defined by itself with fixtures.
First of all, let’s understand that the front and rear levels of the use case are as follows:
1. Module level: Global, the entire module is run only once, prior to test cases.
2. Class level: defined in the class, only valid for this class. cls decorator similar to unittest
3. Function level: only valid for functions, not for functions under classes.
4. Method level: defined in the class, each use case is executed once
def setup_module():
print('\
run the entire module only once')
def teardown_module():
print('\
run only once after the whole module')
def setup_function():
print('\
Functions that are not in the class, only run once per use case before')
def teardown_function():
print('\
Functions not in the class, run only once after each use case')
def test_ab():
b = 2
assert b < 3
def test_aba():
b = 2
assert b < 3
class Test_api():
def setup_class(self):
print('\
This type of use case is only executed once')
def teardown_class(self):
print('\
This type of use case will only be executed once')
def setup_method(self):
print('\
This kind of use case is only executed once before')
def teardown_method(self):
print('\
Execute once after each use case of this class')
def test_aa(self):
a = 1
print('\
I am a use case: a') # pytest -s displays the printed content
assert a > 0
def test_b(self):
b = 2
assert b < 3
operation result:
pytest automated testing framework: Learn the pytest automated testing framework in 3 days, and you will read it for me when you cry_哔哩哔哩_bilibilihttps://www.bilibili.com/video/BV1oX4y1Z7yw/?spm_id_from=333.999.0.0
2. This is the original usage. Let’s look at using Fixture. Fixture is actually customizing pytest to perform pre- and post-use operations. First, create a conftest.py file (specify this name), import the pytest module, and use the pytest.fixture decorator. The default level is, function level:
Other use case files can be called, define a function as follows, and inherit the login function in the conftest.py file to call:
# conftest.py configuration needs to pay attention to the following points:
# The name of the conftest.py configuration script is fixed and cannot be changed
# conftest.py and the running use case must be under the same pakage, and there is an __init__.py file
# No need to import conftest.py, pytest use cases will be automatically searched
import pytest
def test_one(login):
print("After logging in, operate 111")
# def test_two():
# print("Operation 222")
#
# def test_three(login):
# print("After login, operation 333")
operation result:
3. Extended usage, multiple custom functions and global level display: (global, such as used to log in to obtain token, other use case modules do not need to log in again)
import pytest
def test_one(login):
print("After logging in, operate 111")
def test_two(login, open_page):
print("Test case 2")
def test_three(open_page):
print("Test case 3")
the
operation result:
Careful people should be able to know that test case 2 does not call the login function, because the pre-setting is a shared mode, similar to a global function.
Parameterization difference
Parameterized application scenarios, the use case of a scenario will use multiple pieces of data for verification, such as the login function will use the correct username and password to log in, wrong username and correct password, correct username and wrong password Wait for the test, then you can use the parameterization in the framework to complete the test conveniently.
Parameterization is data-driven thinking, that is, multiple sets of data tests can be performed in one test case, and each set of data is separate and independent.
Unittest parameterization is actually: ddt, called data-driven.
pytest data-driven, is parameterized, use @pytest.mark.parametrize
1. First look at how unittest is parameterized:
test_data = [1,2,3]
@ddt.ddt
class Testddt(unittest. TestCase):
@ddt.data(*test_data)
def test_001(self, get_data):
print(get_data)
if __name__ == '__main__':
unittest. main()
operation result:
2. Usage of parameterization in pytest
In front of the test case add:
@pytest.mark.parametrize(“parameter name”, list data)
Parameter name: used to receive each item of data and serve as a parameter of the test case.
List data: A set of test data.
@pytest.mark.parametrize(“parameter 1, parameter 2”, [(data 1, data 2), (data 1, data 2)])
Example:
@pytest.mark.parametrize(“a,b,c”,[(1,3,4),(10,35,45),(22.22,22.22,44.44)])
def test_add(a,b,c):
res = a + b
assert res == c
Example:
@pytest.mark.parametrize('data',[1,2,3])
class Testddt(object):
def test_001(self, data):
print(data)
if __name__ == '__main__':
pytest.main(['-sv'])
the
operation result:
Summary
The above is the difference between the unittest and pytest testing frameworks, seven main differences, two examples of differences have been mentioned here, and the other five will be added when there is time.
pytest automated testing framework: Learn the Pytest automated testing framework in 3 days, and you will read it for me when you cry_哔哩哔哩_bilibilihttps://www.bilibili.com/video/BV1oX4y1Z7yw/?spm_id_from=333.999.0.0
