关于Pytest fixtures，根据官方文档介绍：fixture用于提供一个固定的基线，使 Cases 可以在此基础上可靠地、重复地执行。
对比 PyUnit 经典的setup/teardown形式，它在以下方面有了明显的改进：
fixture拥有一个明确的名称，通过声明使其能够在函数、类、模块，甚至整个测试会话中被激活使用；
fixture以一种模块化的方式实现，原因在于每一个fixture的名字都能触发一个fixture函数，而这个函数本身又能调用其它的fixture；
fixture的管理从简单的单元测试扩展到复杂的功能测试，允许通过配置和组件选项参数化fixture和测试用例，或者跨功能、类、模块，甚至整个测试会话复用fixture。
一句话概括：在整个测试执行的上下文中，fixture扮演注入者（injector）的角色，而测试用例扮演消费者（client）的角色，测试用例可以轻松的接收和处理需要预初始化操作的应用对象，而不用过分关心其实现的具体细节。
fixture的实例化顺序
fixture支持的作用域(Scope)：function(default)、class、module、package、session。
其中，package作用域是在 pytest 3.7 的版本中，正式引入的，目前仍处于实验性阶段。
多个fixture的实例化顺序，遵循以下原则：
高级别作用域的（例如：session）优先于 低级别的作用域的（例如：class或者function）实例化；
相同级别作用域的，其实例化顺序遵循它们在测试用例中被声明的顺序（也就是形参的顺序），或者fixture之间的相互调用关系；
指明autouse=True的fixture，先于其同级别的其它fixture实例化。
fixture实现teardown功能
有以下几种方法（注意：在yield之前或者addfinalizer注册之前代码发生错误退出的，都不会再执行后续的清理操作）：
将fixture变为生成器方法（推荐）
即将fixture函数中的return关键字替换成yield，则yield之后的代码，就是我们要的清理操作。
@pytest.fixture(scope='session', autouse=True)
def clear_token():
yield
from libs.redis_m import RedisManager
rdm = RedisManager()
rdm.expire_token(seconds=60)
使用addfinalizer方法
fixture函数能够接收一个request的参数，表示测试请求的上下文（下面会详细介绍），我们可以使用request.addfinalizer方法为fixture添加清理函数。
@pytest.fixture()
def smtp_connection_fin(request):
smtp_connection = smtplib.SMTP("smtp.163.com", 25, timeout=5)
def fin():
smtp_connection.close()
request.addfinalizer(fin)
return smtp_connection
使用with写法（不推荐）
对于支持with写法的对象，我们也可以隐式的执行它的清理操作：
@pytest.fixture()
def smtp_connection_yield():
with smtplib.SMTP("smtp.163.com", 25, timeout=5) as smtp_connection:
yield smtp_connection
fixture可以访问测试请求的上下文
fixture函数可以接收一个request的参数，表示测试用例、类、模块，甚至测试会话的上下文环境，例如可以扩展下上面的smtp_connection_yield，让其根据不同的测试模块使用不同的服务器：
@pytest.fixture(scope='module')
def smtp_connection_request(request):
server, port = getattr(request.module, 'smtp_server', ("smtp.163.com", 25))
with smtplib.SMTP(server, port, timeout=5) as smtp_connection:
yield smtp_connection
print("断开 %s：%d" % (server, port))
在测试模块中指定smtp_server：
smtp_server = ("mail.python.org", 587)
def test_163(smtp_connection_request):
response, _ = smtp_connection_request.ehlo()
assert response == 250
fixture返回工厂函数
如果需要在一个测试用例(function)中，多次使用同一个fixture实例，相对于直接返回数据，更好的方法是返回一个产生数据的工厂函数。并且，对于工厂函数产生的数据，也可以在fixture中对其管理：
@pytest.fixture
def make_customer_record():
# 记录生产的数据
created_records = []
# 工厂
def _make_customer_record(name):
record = models.Customer(name=name, orders=[])
created_records.append(record)
return record
yield _make_customer_record
# 销毁数据
for record in created_records:
record.destroy()
def test_customer_records(make_customer_record):
customer_1 = make_customer_record("Lisa")
customer_2 = make_customer_record("Mike")
customer_3 = make_customer_record("Meredith")
fixture的参数化
如果你需要在一系列的测试用例的执行中，每轮执行都使用同一个fixture，但是有不同的依赖场景，那么可以考虑对fixture进行参数化，这种方式适用于对多场景的功能模块进行详尽的测试。
@pytest.fixture(scope='module', params=['smtp.163.com', "mail.python.org"])
def smtp_connection_params(request):
server = request.param
with smtplib.SMTP(server, 587, timeout=5) as smtp_connection:
yield smtp_connection
def test_parames(smtp_connection_params):
response, _ = smtp_connection_params.ehlo()
assert response == 250
在不同的层级上覆写fixture
注意：低级别的作用域可以调用高级别的作用域，但是高级别的作用域调用低级别的作用域会返回一个ScopeMismatch的异常。
在大型的测试中，可能需要在本地覆盖项目级别的fixture，以增加可读性和便于维护：
@pytest.fixture(scope="module", autouse=True)
def init(frag_login):
pass
@pytest.fixture(scope='session')
def active_user_account(cmd_line_args, conf):
tail_num = cmd_line_args.get("tailnum", None)
if tail_num is None:
tail_num = "1"
for user in conf['unified']:
if str(user['uid'])[-1] == tail_num:
return user
msg = f"尾号[{tail_num}], 在配置文件中未找到"
logger.error(msg)
raise ValueError(msg)
最后感谢每一个认真阅读我文章的人，下方这份完整的软件测试教程已经整理上传完成，需要的朋友们可以文末自行领取：【保证100%免费】
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！
