Watcher 功能测试基础设施¶

https://blueprints.launchpad.net/watcher/+spec/functional-test-infrastructure

为 Watcher 引入功能测试基础设施，能够以最少的模拟方式测试多组件工作流。这提高了对复杂服务交互（API、决策引擎、应用器）的测试覆盖率，并为需要集成测试才能重现的错误提供了回归保护。

问题描述¶

Watcher 目前具有出色的单元测试覆盖率，但缺乏验证多个组件协同工作的的功能测试。这种差距使得难以

捕获由于过度模拟而单元测试无法发现的集成错误
测试真实的工作流（审计 → 策略 → 行动计划 → 应用器）
验证服务之间使用真实消息传递的 RPC 交互
重现需要服务交互的复杂错误
使用真实的 WSGI 应用程序测试 API 行为
在真实场景中验证通知的发出

带有大量模拟的单元测试可能会给出虚假的信心 - 测试通过，但集成的系统在生产环境中失败。功能测试通过使用最少的模拟来测试真实的代码路径，填补了这一空白。

用例¶

作为 Watcher 开发人员，我希望编写功能测试，以便在多个组件交互时验证我的更改是否正常工作，而无需完整的 OpenStack 部署。

作为 Watcher 核心评审员，我希望对复杂的错误修复进行功能测试，以便确信该错误已真正修复并且不会再次出现。

作为 Watcher 操作员，我受益于功能测试在发布前捕获集成错误，从而获得更稳定的部署。

作为 Watcher 贡献者，我希望获得清晰的示例和文档，以便进行功能测试，这样我就可以在不需要深入了解测试基础设施的情况下为我的功能添加测试。

提议的变更¶

实现针对 Watcher 架构（Pecan API、决策引擎、应用器服务）调整的，基于 OpenStack 模式（Nova、Placement）的功能测试基础设施。

该基础设施提供

重组的测试结构：watcher/tests/unit/ 和 watcher/tests/functional/
用于数据库、RPC、外部服务、API 服务器的可重用 fixtures
WatcherFunctionalTestCase 基类，具有自动 fixture 设置
Gabbi (YAML) 测试，用于声明式 API 合同测试
回归测试框架和文档
功能测试贡献者指南

该实现遵循“最小化模拟，最大化真实性” - 功能测试使用真实的 Watcher 代码（API、数据库、RPC），并且仅模拟外部服务（Nova、Gnocchi）。

关键设计

SQLite 内存中，带有模式缓存以提高速度
oslo.messaging 假驱动程序，用于确定性 RPC
wsgi-intercept 用于进程内 HTTP（无网络 I/O）
Python 和 Gabbi (YAML) 测试格式
重用现有 helpers (watcher/tests/db/utils.py)

目录结构

watcher/tests/
├── unit/                      # All existing tests (moved)
│   ├── api/
│   ├── decision_engine/
│   ├── applier/
│   └── ...
├── functional/                # New functional tests
│   ├── base.py               # WatcherFunctionalTestCase
│   ├── test_api_audits.py    # Python functional tests
│   ├── test_workflows.py     # End-to-end workflow tests
│   ├── test_api_gabbi.py     # Gabbi test loader
│   ├── fixtures/             # Gabbi-specific fixtures
│   │   ├── gabbi.py
│   │   └── capture.py
│   ├── gabbits/              # Gabbi YAML tests
│   │   ├── audit-lifecycle.yaml
│   │   ├── microversions.yaml
│   │   └── ...
│   └── regressions/          # Bug-specific tests
│       └── test_bug_*.py
├── local_fixtures/            # Shared fixtures
│   ├── conf.py               # Configuration fixture
│   ├── database.py           # Database fixture
│   ├── rpc.py                # RPC fixtures
│   ├── notifications.py      # Notification capture
│   ├── api.py                # API server fixture
│   ├── service.py            # Service fixture
│   ├── nova.py               # Nova mock
│   └── gnocchi.py            # Gnocchi mock
├── fixtures/                  # Existing test fixtures
│   └── watcher.py
└── helpers.py                 # Test helper functions

测试执行

tox -e py3                    # Unit tests
tox -e functional             # All functional tests
tox -e functional-regression  # Regression tests only

备选方案¶

仅完整集成测试：通过 DevStack 部署真实的外部服务。被拒绝 - 太慢（30+ 分钟），设置复杂，网络不稳定。

仅单元测试：依赖于现有的单元测试和 Tempest。被拒绝 - 无法发现集成错误，难以重现复杂场景。

Docker 容器：在容器中运行服务。被拒绝 - 增加了复杂性，速度较慢，与 OpenStack 模式不一致。

仅 Tempest：仅使用 Tempest 进行集成。被拒绝 - 对于常规开发来说太慢，不能替代功能测试。

数据模型影响¶

无。功能测试使用现有的数据模型。数据库 fixture 应用现有的迁移来创建模式。

REST API 影响¶

无。功能测试验证现有的 API 行为。Gabbi 测试基础设施将提高 API 测试覆盖率并使微版本测试更容易，但不会更改 API 本身。

安全影响¶

无。

通知影响¶

无。功能测试验证现有的通知行为。通知 fixture 捕获发出的通知以进行验证，但不会更改通知发出逻辑。

其他最终用户影响¶

无。

性能影响¶

无

其他部署者影响¶

无。

开发人员影响¶

积极影响：更轻松的端到端测试，更好的回归保护，更清晰的测试组织，更低的 API 测试门槛。

学习曲线：开发人员学习何时使用功能测试与单元测试，文档提供指南和示例。

代码审查期望：对复杂的错误修复、多组件工作流、API 更改（Gabbi 测试）和 RPC 功能进行功能测试。

实现¶

负责人¶

主要负责人

sean-k-mooney

其他贡献者

无

工作项¶

提取现有的 fixtures 并创建测试 helpers
重组测试：移动到 unit/，创建 functional/
核心 fixtures：数据库、RPC、通知、配置
服务 fixtures：Nova、Gnocchi 模拟
API fixture：带有 wsgi-intercept 的 Pecan
服务 fixture：决策引擎、应用器
基测试类：WatcherFunctionalTestCase
Gabbi 基础设施：loader、fixtures、YAML 示例
示例测试：API 测试、工作流测试
回归框架：目录结构、指南、README
文档：功能/Gabbi 测试的贡献者指南
CI 集成：tox.ini、.zuul.yaml、stestr 配置

请参阅详细的实施计划：https://gist.github.com/SeanMooney/43afa55282d2286a312eae7f3c7709e2

依赖项¶

没有新的运行时依赖项。

测试依赖项将使用现有库扩展：nova 和 placement 中使用。

gabbi - YAML HTTP 测试（在 requirements 中）
wsgi-intercept - 进程内 HTTP（在 requirements 中）
oslo.messaging - 带有假驱动程序的 RPC（正在使用）
oslo.db - 数据库 fixtures（正在使用）
oslo.config - 配置管理（正在使用）
oslo.log - 日志记录（正在使用）
oslo.policy - 策略执行（正在使用）

测试¶

验证方法：在继续之前验证每个阶段。单元测试套件验证重组，fixture 测试验证清理/行为，zuul 作业将在编写最小测试用例后添加，并将随着功能测试的扩展而自我验证功能测试。

文档影响¶

新的文档

功能测试贡献者指南 (doc/source/contributor/functional-testing.rst)：涵盖功能与单元测试，Python 和 Gabbi 测试编写，fixture 使用，运行/调试，最佳实践
回归测试指南 (watcher/tests/functional/regressions/README.rst)：何时编写回归测试，命名约定，结构要求
API 文档：Gabbi 测试作为可执行示例

更新的文档

测试指南：添加功能与单元测试部分
README.rst：使用功能测试命令更新

参考资料¶

实施细节

详细的实施计划：https://gist.github.com/SeanMooney/43afa55282d2286a312eae7f3c7709e2
Nova 功能测试的工作方式：https://gist.github.com/SeanMooney/0bc41721481dd6e5918a4504c956f882
Gabbi 测试在 Placement 中工作方式：https://gist.github.com/SeanMooney/36f2ef20bd5cb4c853af23c581b917fc

OpenStack 参考

历史¶

修订版¶
发布名称	描述
2026.1	引入

Watcher 的功能测试基础设施