pyclaw：Python 自动化测试框架

为什么写 pyclaw

在日常 Python 开发中，我需要一个轻量级的测试执行框架来管理集成测试和端到端测试。pytest 在单元测试层面做得很好，但当我需要编排多步骤的集成测试流程——比如：先启动服务 → 执行 API 测试 → 运行数据库验证 → 清理环境——pytest 的 fixture 机制就不太够用了。pyclaw 正是为了解决这个场景：面向流程的测试编排。

核心设计

用例管理     →  test_case.py（定义测试步骤）
执行引擎     →  runner.py（顺序/并行执行）
报告生成     →  reporter.py（结构化输出）

用例模型

每个测试用例是一个继承 TestCase 的类，包含多个步骤：

class ApiTestCase(TestCase):
    steps = [
        Step("启动服务", start_service),
        Step("创建资源", create_resource, retry=3),
        Step("验证响应", verify_response, timeout=30),
        Step("清理", cleanup, always_run=True),
    ]

关键设计点：

• always_run：即使前面步骤失败，清理步骤也执行
• retry：网络请求等不稳定操作自动重试
• timeout：单步骤超时保护，防止死等

执行引擎

支持两种模式：

1. 顺序执行：步骤按定义顺序执行，前一步失败后停止（除非标记为 always_run）
2. 并行执行：多个独立用例同时运行，适合回归测试场景

报告输出

测试结果输出为 JSON 格式，包含每步的执行时间、通过/失败、错误信息。可以对接 CI/CD 系统做进一步分析。

实际使用场景

在我之前的数据处理项目中（清洗 70 万条数据），用 pyclaw 编排了数据管道的端到端测试：

class DataPipelineTest(TestCase):
    steps = [
        Step("连接 MySQL 源库", connect_source),
        Step("执行清洗脚本", run_clean, timeout=300),
        Step("验证清洗结果", validate_counts),
        Step("插入目标表", insert_target),
        Step("验证完整性", verify_integrity),
    ]

相比 pytest，这种编排方式让测试流程一目了然，也方便新成员理解整个管道的执行顺序。

踩坑

测试隔离：并行执行时不同用例共享数据库状态导致互相干扰。解决方案：每个用例在独立的事务中执行，测试结束后回滚。

超时处理：Python 的线程超时不如 asyncio 优雅。如果用 asyncio 重写可以减少时间管理的复杂度。

---

简而言之，pyclaw 是我在项目实践中感到 pytest 的编排能力不够用时的解决方案。它不替代单元测试，而是补充集成测试和 E2E 测试的编排需求。