基于pytest-bdd的项目目录结构和命名规范

pytest-bdd 的文件的命名规范

pytest-bdd 是基于pytest 之上，所以需要遵循pytest 的命名规则才能进行测试，具体有：

测试文件名必须以*test.py或者test*.py命名测试函数必须以 test_开头

在pytest-bdd中存在两类文件：

以 .feature 结尾的用户场景文件以 .py 结尾的测试代码。这里又细分为两类： 以 @given，@when，@then 注解的步骤函数，这些函数名没有强制限制， 也可以借鉴beheave的写法以 step_开头。以 @scenario 注解的测试场景函数，这个函数名需要以 test_ 开头， 因为这样才会被pytest 识别。

举例来看： @given，@when，@then 的步骤函数的示例：

@pytest.fixture @given("I have a calculator") def calculator(): return Calculator() @when(parsers.parse('I enter "{a}" and "{b}"')) def enter_numbers(calculator, a, b): calculator.a = int(a) calculator.b = int(b) @then(parsers.parse('the result should be "{result}"')) def verify_result(calculator, result): assert calculator.add(calculator.a, calculator.b) == int(result)

@scenario 注解的测试场景函数的示例：

@scenario('../features/calculator.feature','Add two numbers') def test_add(): pass @scenario 本身没有实际的内容，只是一个占位符，关联场景和步骤，但是又不可少 关于 @scenario

@scenario是 pytest-bdd 框架中的一个装饰器，用于标记一个 BDD 场景并将其与编写的测试函数关联起来。 @scenario装饰器可以用来定义一个场景，并确定它所属的 feature 和 scenario。其语法如下：

@scenario('<feature_file_path>', '<scenario_name>') def test_my_scenario(): pass

其中，<feature_file_path>是 feature 文件的路径，<scenario_name>是场景的名称。在测试方法中不需要任何具体的测试步骤。相反，pytest-bdd 将自动加载与场景匹配的步骤，并在执行测试时逐步执行它们。这意味着测试方法本身只是一个占位符，其定义的唯一目的是将场景与步骤关联起来。

使用@scenario装饰器需要遵循一定的规则，如下：

一个@scenario装饰器用于定义一个场景。

必须指定该场景所属的 feature 文件的路径和场景名称。

测试函数的名称必须与场景名称匹配。

测试函数的参数必须与场景步骤的参数名称相匹配。

测试函数必须使用 BDD 关键字来编写场景步骤。

pytest-bdd 将自动加载与场景匹配的步骤，并在执行测试时逐步执行它们。

可以将多个场景分组在同一个 feature 文件中，并在同一个测试类中执行它们。

使用pytest-bdd的项目的目录结构

基于以上，目录的设计如下： 1…feature 场景文件放置在项目根目录的 features目录中。[非强制] 2. 步骤函数和场景函数可以放在一个.py文件中， 也可以放在两个 .py文件中。 3. 包含场景函数的.py 需要以test_ 开头 [强制] 4. 测试步骤的文件放置在项目根目录的steps 或step_defs 目录中[非强制] 5. 场景函数如果分拆出来，放置在根目录的 test_cases目录中[非强制] 6. 在基于面向对象的设计中，可以一个类一个场景文件， 也可以一个功能一个场景文件。[非强制]

基于以上原则，提供的几个目录结构示例如下：

目录结构1：

步骤函数和场景函数放在一起，一个功能一个场景文件：

├────features/ # 用户场景 │ ├────user/ │ │ ├────create_user.feature │ ├────login.feature ├────step_defs/ # 步骤函数和测试场景 │ ├────user/ │ │ ├────test_create_user.py │ └────test_login.py 目录结构2：

步骤函数和场景函数放在一起，一个类一个场景文件：

├────features/ # 用户场景 │ ├────user.feature │ ├────login.feature ├────step_defs/ # 步骤函数和测试场景 │ ├────user.feature │ └────test_login.py 目录结构3： ├────features/ # 用户场景 │ ├────user/ │ │ ├────create_user.feature │ ├────login.feature ├────step_defs/ # 步骤函数 │ ├────user/ │ │ ├────create_user_steps.py │ └────login_steps.py ├────test_case/ # 测试场景 │ ├────test_user/ │ │ ├────test_create_user.py │ └────test_login.py

其他还可以用 cases和 test_cases 来命名，类似如下：

├────cases/ # 用户场景 │ ├────projects/ │ │ ├────create_project.features │ ├────login.features ├────test_cases/ # 步骤函数和测试场景 │ ├────projects/ │ │ ├────test_create_project.py │ └────test_login.py ├────test_cases/ # 测试用例 │ ├────features/ # 用户场景 │ │ ├────login.features │ ├────step_defs/ # 步骤函数和测试场景 │ │ ├────test_login.py 以测试角度出发的目录

上面的目录规范是将BDD的规范文件和测试作为独立的部分， 也有的项目从测试角度出发，将BDD的文件作为测试的一部分， 统一放入项目的tests 目录中，

|-- tests | |-- features | | |-- step_definitions | | | |-- __init__.py | | | |-- test_steps.py | | |-- support | | | |-- conftest.py | | | |-- env.py | | | |-- hooks.py | | |-- feature1.feature | | |-- feature2.feature | |-- unit | | |-- __init__.py | | |-- test_module1.py | | |-- test_module2.py | |-- __init__.py | |-- conftest.py |-- setup.py |-- requirements.txt |-- README.md tests目录包含所有测试相关文件，其中features目录用于存放 BDD 测试用例和相关文件，unit目录用于存放其他类型的测试用例。step_definitions目录用于存放实现 BDD 测试用例步骤的 Python 脚本。每个 BDD 测试用例的步骤都应该在这里实现support目录用于存放 BDD 测试用例所需的支持文件，比如环境设置、钩子函数等。conftest.py文件放在tests目录下，用于实现项目级别的配置和夹具设置。setup.py文件是一个 Python 包的安装脚本。requirements.txt文件用于存储项目依赖库的清单。README.md文件是项目的说明文档。

如果从BDD的定义和作用来看的话，这种目录结构就有点混淆了 BDD和测试的概念，因为BDD是有终端用户参与进来的部分， 目录层级较深不利于使用，个人是比较不建议这种方式。

---

---