baozaotumao
df48c36422
把规则从原 ppt-gen 项目泛化为通用脚手架，覆盖 19 个文件： - ddd/architecture/design-discipline/error-codes/communication-* 等： 领域术语、错误码、消息示例、扩展点、状态流统一为「订单」示范域 - agent-dag/agent.md/agent-concurrency/agent-llm-*：DAG 节点、配置、并发、 LLM 适配从「对话→预览→生成→截图→合成」改为「intake→process→validate→finalize」 - backend-db：Session 实体/状态机/ORM/仓储/checkpoint 对齐新流水线 - 移除幻灯片专属依赖与产物：agent 去 playwright/python-pptx， Dockerfile 去 Chromium 系统库，.gitignore 去 *.pptx - 保留合法通用项：ANSI（PTY 处理）、Playwright（E2E 测试工具）、Gemini CLI（真实 provider） 验证：gemini-cli/openai-api 两变体生成退出 0，生成项目零 PPT 残留， backend/agent 骨架均可 import 运行。
1.9 KiB
1.9 KiB
TDD 开发流程与测试策略
Red-Green-Refactor（强制）+ 测试金字塔 + 覆盖率门禁。
TDD 开发流程（测试先行，强制）
严禁先写实现后补测试。 测试是契约的可执行规格，先于实现存在。每个单元按 Red-Green-Refactor 循环推进：
- Red：依据契约写一个失败测试，描述期望行为（此时无实现）
- Green：写最小实现让测试通过，不做超前设计
- Refactor：在测试保护下重构，消除重复、提升内聚，测试须始终为绿
- 一个 R-G-R 循环对应一次原子提交（
test:与feat:可分可合） - 测试名描述「行为 + 期望」，而非实现细节
- 学派：应用/编排层面向端口用 mockist（伦敦学派，mock 协作者验交互）；领域纯逻辑用 classicist（芝加哥学派，验状态、不 mock）
- 顺序恒为：定契约 → 写测试（Red）→ 实现（Green）→ 重构（Refactor）
测试策略
承接 TDD 产出的单元层，补齐集成与 E2E。测试金字塔，底层为主。覆盖率在 CI 强制，不达标禁止合并。
| 层级 | 范围 | 占比 | 工具 |
|---|---|---|---|
| 单元 | 纯函数、节点、service、hook（mock 边界） | ~70% | pytest / vitest |
| 集成 | 路由+DB、WS 代理转发、DAG 串联 | ~25% | httpx / Testing Library |
| E2E | 一条龙：输入→处理→结果（mock 外部依赖输出） | ~5% | Playwright |
- 覆盖率门禁：行覆盖 ≥ 80%（核心 hooks/schemas/dag 节点 100%），CI
--cov-fail-under=80/ vitestcoverage.thresholds - mock 边界清晰：只 mock 外部依赖（LLM CLI 子进程、第三方 API、网络），不 mock 被测对象内部
- 测试命名：
test_<被测>_<场景>_<期望>；一个测试只断言一件事 - 确定性：禁止依赖真实时间/网络/随机；用 fixture 注入