历史记录¶
此页面列出了 pytest 早期版本的功能或行为，这些功能或行为在多年间发生了变化。它们在此处作为历史记录保留，以便查看旧代码的用户可以找到与它们相关的文档。
标记的改进和迭代¶
在 3.6 版本中更改。
pytest 的标记实现传统上通过简单地更新函数的 __dict__ 属性来累积添加标记。因此，标记会以令人惊讶的方式无意中沿着类层次结构传递。此外，检索它们的 API 不一致，因为来自参数化的标记与使用 @pytest.mark 装饰器添加的标记以及通过 node.add_marker 添加的标记以不同的方式存储。
这种状态使得在不深入了解内部原理的情况下，从标记中正确使用数据在技术上几乎不可能，从而导致更高级用法中出现细微且难以理解的错误。
根据标记的声明/更改方式，可能会得到 MarkerInfo，其中可能包含来自同级类的标记，当标记来自参数化或 node.add_marker 调用时，会得到 MarkDecorators，从而丢弃之前的标记。此外，MarkerInfo 表现得像单个标记，但实际上它表示同名多个标记的合并视图。
最重要的是，模块、类和函数/方法无法以相同的方式访问标记。实际上，即使标记在类/模块上声明，也只能在函数中访问标记。
pytest 3.6 中引入了一个新的 API 来访问标记，以解决初始设计中的问题，提供了 _pytest.nodes.Node.iter_markers() 方法以一致的方式迭代标记并重新设计了内部结构，这解决了初始设计中的许多问题。
更新代码¶
旧的 Node.get_marker(name) 函数被认为是已弃用的，因为它返回一个内部 MarkerInfo 对象，该对象包含应用于该节点的合并名称、*args 和 **kwargs 的所有标记。
一般来说，处理标记有两种情况
1. 标记相互覆盖。顺序很重要，但您只想将标记视为单个项目。例如，模块级别的 log_level('info') 可以被特定测试的 log_level('debug') 覆盖。
在这种情况下，请使用
Node.get_closest_marker(name)# replace this: marker = item.get_marker("log_level") if marker: level = marker.args[0] # by this: marker = item.get_closest_marker("log_level") if marker: level = marker.args[0]
2. 标记以累加的方式组合。例如，skipif(condition) 标记意味着您只想评估所有标记，顺序甚至无关紧要。您可能希望在此处将标记视为一个集合。
在这种情况下，迭代每个标记并单独处理它们的
*args和**kwargs。# replace this skipif = item.get_marker("skipif") if skipif: for condition in skipif.args: # eval condition ... # by this: for skipif in item.iter_markers("skipif"): condition = skipif.args[0] # eval condition
如果您不确定或有任何疑问，请考虑打开 一个 issue。
缓存插件集成到核心中¶
核心缓存 插件的功能以前作为名为 pytest-cache 的第三方插件分发。核心插件在命令行选项和 API 用法方面是兼容的，但您只能存储/接收测试运行之间可 json 序列化的数据。
funcargs 和 pytest_funcarg__¶
在 2.3 之前的版本中，没有 @pytest.fixture 标记，您必须对 fixture 工厂使用神奇的 pytest_funcarg__NAME 前缀。这仍然存在并将继续得到支持，但不再作为声明 fixture 函数的主要方式进行宣传。
@pytest.yield_fixture 装饰器¶
在 2.10 版本之前，为了使用 yield 语句执行 teardown 代码，必须使用 yield_fixture 标记标记 fixture。从 2.10 版本开始，普通 fixture 可以直接使用 yield，因此不再需要 yield_fixture 装饰器，并被认为是已弃用的。
[pytest] setup.cfg 中的标头¶
在 3.0 之前，支持的节名称是 [pytest]。由于这可能会与某些 distutils 命令冲突，因此 setup.cfg 文件的推荐节名称现在是 [tool:pytest]。
请注意，对于 pytest.ini 和 tox.ini 文件，节名称是 [pytest]。
将标记应用于 @pytest.mark.parametrize 参数¶
在 3.1 版本之前，用于标记值的支持机制使用了以下语法
import pytest
@pytest.mark.parametrize(
"test_input,expected", [("3+5", 8), ("2+4", 6), pytest.mark.xfail(("6*9", 42))]
)
def test_eval(test_input, expected):
assert eval(test_input) == expected
这是一个支持该功能的初始 hack，但很快就被证明是不完整的，对于传递函数或应用具有相同名称但不同参数的多个标记会损坏。
旧语法计划在 pytest-4.0 中删除。
@pytest.mark.parametrize 参数名称作为元组¶
在 2.4 之前的版本中，需要将参数名称指定为元组。这仍然有效，但现在首先宣传更简单的 "name1,name2,..." 逗号分隔字符串语法，因为它更容易编写并产生更少的行噪声。
setup: 现在是“autouse fixture”¶
在 pytest-2.3 版本之前的开发过程中，使用了名称 pytest.setup，但在发布之前，它被重命名并移动，成为通用 fixture 机制的一部分，即 Autouse fixtures（您不必请求的 fixtures）
条件作为字符串而不是布尔值¶
在 pytest-2.4 之前，指定 skipif/xfail 条件的唯一方法是使用字符串
import sys
@pytest.mark.skipif("sys.version_info >= (3,3)")
def test_function(): ...
在测试函数 setup 期间，通过调用 eval('sys.version_info >= (3,0)', namespace) 来评估 skipif 条件。命名空间包含所有模块全局变量，以及 os 和 sys (至少)。
自 pytest-2.4 以来，布尔条件 被认为是更可取的，因为标记可以在测试模块之间自由导入。使用字符串时，您不仅需要导入标记，还需要导入标记使用的所有变量，这违反了封装性。
将条件指定为字符串的原因是 pytest 可以仅基于条件字符串报告 skip 条件的摘要。使用布尔条件时，您需要指定 reason 字符串。
请注意，字符串条件将继续完全受支持，如果您不需要交叉导入标记，则可以自由使用它们。
在 pytest.mark.skipif(conditionstring) 或 pytest.mark.xfail(conditionstring) 中评估条件字符串发生在命名空间字典中，该字典的构造方式如下
命名空间通过将
sys和os模块以及 pytestconfig对象放入其中来初始化。使用应用表达式的测试函数的模块全局变量进行更新。
pytest config 对象允许您基于您可能添加的测试配置值跳过
@pytest.mark.skipif("not config.getvalue('db')")
def test_function(): ...
与“布尔条件”等效的是
@pytest.mark.skipif(not pytest.config.getvalue("db"), reason="--db was not specified")
def test_function():
pass
注意
您不能在 pytest 的参数解析发生之前导入的代码中使用 pytest.config.getvalue()。例如，conftest.py 文件在命令行解析之前导入，因此 config.getvalue() 将无法正确执行。
pytest.set_trace()¶
在 2.4 版本之前，要在代码中设置断点，需要使用 pytest.set_trace()
import pytest
def test_function():
...
pytest.set_trace() # invoke PDB debugger and tracing
不再需要这样做，可以直接使用原生的 import pdb;pdb.set_trace() 调用。
有关更多详细信息，请参阅 设置断点。
“兼容性”属性¶
通过 Node 实例访问 Module、Function、Class、Instance、File 和 Item 长期以来一直被记录为已弃用，但从 pytest 3.9 及更高版本开始发出警告。
用户应该只 import pytest 并使用 pytest 模块访问这些对象。