第2章 · 夹具设计原则：DRY、单一职责、可组合性、可维护性

UI 测试夹具（Fixture）的质量直接决定自动化套件的长期健康度。粗放的夹具往往出现重复加载、职责混杂、难以拼接、改一处而碎全盘等问题。本章以 DRY、单一职责、可组合性、可维护性 四条原则为骨架，阐述它们在夹具设计与代码实现中的具体落地方式。

2.1 DRY —— 消除重复，提升复用

原理：在 pytest 等框架中，conftest.py 是 DRY 的天然载体。将多次出现的 setup/teardown 提升为全局级或模块级 fixture，避免每个测试文件都写同一套逻辑。

实现流程

1. 识别重复代码：扫描整个项目，提取出现 ≥3 次的前置操作（如浏览器打开、用户登录、数据插入）。
2. 迁入统一 fixture：在 conftest.py 中定义并标记作用域（scope="module" / "session"）。
3. 参数化共享数据：使用 @pytest.fixture(params=[...]) 提供多组数据，避免每个测试拷贝数据列表。
4. 移除冗余代码：逐个清理原先的重复 setup 调用，确保只保留注入式使用。

# conftest.py — DRY 示例
import pytest
from selenium import webdriver

@pytest.fixture(scope="session")
def shared_driver():
    driver = webdriver.Chrome()
    yield driver
    driver.quit()

@pytest.fixture(scope="module")
def logged_in_user(shared_driver):
    shared_driver.get("https://example.com/login")
    # 执行统一登录流程
    yield "user_"
    # 无需登出，由 session fixture 处理资源释放

2.2 单一职责 —— 每个 fixture 只做一件事

原理：一个 fixture 不应该既负责数据库连接又负责页面截图。职责边界模糊会导致 fixture 之间隐式依赖，破坏确定性。

实现流程

1. 列出 fixture 的所有行为，将其拆分为原子操作。
2. 每个 fixture 只处理一个外部资源或一组紧密相关状态（如仅处理配置读取）。
3. 通过 fixture 依赖树组合小 fixture，而不是在一个 fixture 中写复杂流程。

# 单一职责拆分示例 — 不符合
@pytest.fixture
def bad_fixture():
    db = connect_db()
    config = load_config()
    driver = webdriver.Chrome()
    yield db, config, driver
    # 清理三个资源，职责混杂

# 符合单一职责
@pytest.fixture
def db_conn():
    conn = connect_db()
    yield conn
    conn.close()

@pytest.fixture
def test_config():
    return load_config()

@pytest.fixture
def browser(test_config):
    driver = webdriver.Chrome()
    yield driver
    driver.quit()

2.3 可组合性 —— 拼装而非继承

原理：通过参数化、Fixture 工厂、或 pytest 的 @pytest.fixture 的自动依赖组合，将多个小 fixture 按需组合成复杂场景，而不需要为每种组合创建一个新 fixture。

实现流程

1. 创建低层级“原子 fixture”（如 clean_db、session_manager）。
2. 在上层场景中直接把这些原子 fixture 作为参数引用，框架自动按依赖图 resolve。
3. 复杂组合使用 @pytest.fixture 的 params 或 lazy fixture 避免重复定义。

# 可组合夹具示例
@pytest.fixture
def clean_db():
    """每个测试前清空数据库"""
    clear_all_tables()
    yield

@pytest.fixture
def seed_data():
    """注入测试基础数据"""
    insert_sample_data()
    yield

# 组合使用：直接在测试或高层 fixture 中引用
def test_user_registration(clean_db, seed_data, logged_in_user):
    # clean_db 先执行 → seed_data → logged_in_user
    assert check_registration_works()

2.4 可维护性 —— 让 fixture 代码自成文档

原理：可维护性来自一致的生命周期管理、显式命名、以及约定大于配置。fixture 的定义位置、作用域、清理逻辑都应当无需猜测。

实现流程

1. 将 fixture 按照功能模块放入各自的 conftest.py，保持层级清晰。
2. 每个 fixture 添加 docstring 说明资源来源、清理行为和副作用。
3. 清理逻辑统一使用 yield 形式，避免使用 teardown_module 等杂散函数。
4. 定义公共常量或配置 YAML 文件，并由一个 settings fixture 加载，所有其他 fixture 通过它获取路径、账号等参数。

# 可维护性示例 — conftest.py 结构
tests/
├── conftest.py              # session/function 级共享 fixture
├── ui/
│   ├── conftest.py          # 仅 UI 测试相关 fixture
│   └── test_login.py
├── api/
│   ├── conftest.py          # 仅 API 测试相关 fixture
│   └── test_endpoints.py
└── config.yaml              # 全局环境配置

# config.yaml
base_url: "https://staging.example.com"
timeout: 30
admin_user: "admin"

2.5 原则关系与夹具架构图

下图展示了四条原则如何在夹具设计与运行时形成协作网络。DRY 驱动共享资源层，单一职责细分原子服务，可组合性将这些原子拼接为业务场景，可维护性则贯穿整个结构保证正交。

2.6 常见违反原则模式与纠正