test-generator

# 测试生成器 ## 工作流程 ### 1. 读取真实契约 检查目标代码及其： - 类型定义、公开文档、调用方和错误处理路径。 - 现有测试、fixture、测试配置、依赖清单和项目测试命令。 - 输入输出、副作用、状态变化、并发语义和系统边界。 - 适用的仓库规则、Git 状态及本轮允许修改的范围。 区分“代码当前行为”和“产品期望行为”。两者冲突或契约不明确且会改变断言时，先列出证据与待确认假设；不要用测试固化猜测。 ### 2. 选择测试层级 - 纯逻辑优先使用快速、确定的单元测试。 - 在系统边界隔离时间、随机数、文件系统、网络或第三方服务，避免 mock 被测模块的内部实现。 - 需要验证真实组件协作时使用集成测���，可采用临时目录、测试数据库或受控服务，并确保资源隔离和清理。 - 修复缺陷时先写能复现真实问题的最小回归用例，再验证修复。 只覆盖契约或可达路径中真实存在的正常、边界与失败场景。空值、类型错误、超时和数据库异常不是每个函数的固定要求。 ### 3. 设计用例 每个用例应说明： - 对应的契约、缺陷或分支。 - 输入与环境安排。 - 可观察结果，而非内部实现细节。 - 必要的清理和跨用例隔离。 优先参数化重复场景，并沿用仓库现有的测试命名、目录、fixture 和断言风格。不要因项目面向中文用户而强制使用中文函数名。 ### 4. 实现最小测试 - 只修改目标测试文件和确有必要的 fixture。 - 不为了让测试通过而随意修改生产代码；若发现产品缺陷，单独报告或按用户要求修复。 - 不复制未经核实的示例期望值，也不把实现细节写成永久契约。 - Windows 与 Linux 使用路径 API、系统临时目录和显式编码，不硬编码分隔符、`/tmp`、换行、大小写、时区或 locale 行为。 ### 5. 运行与复验 1. 先运行新增或目标测试，确认失败信息与预期一致。 2. 先检查项目脚本是否会下载依赖、访问外部服务或改变共享状态，再按改动风险运行相关测试；必要时运行完整测试、类型检查或覆盖率命令，潜在外部副作用需先获授权。 3. 检查 Git diff，确认没有快照、缓存、覆盖率产物或无关文件。 4. 将基线已有失败与本轮新增失败分开记录。 没有实际运行时，只能说明“已生成、未验证”，不能声称测试通过。 ## 安全与授权边界 - 未经明确授权，不安装或升级测试框架，不修改 lockfile、全局测试配置、CI 或生产代码。 - 未经明确授权，不访问真实网络、生产数据库、���服务或含真实凭据的环境。 - 测试数据不得包含真实个人信息、Token、Cookie、密码或客户数据。 - 测试必须可重复，不依赖执行顺序，并清理创建的临时资源。 - 目标文件已有用户修改时，先检查是否重叠，避免覆盖。 ## 输出 ```markdown ## 测试补充结果 - 目标与契约依据： - 测试层级与框架： - 新增或修改文件： ## 用例 | 场景 | 契约依据 | 预期结果 | |------|----------|----------| ## 验证 - 实际命令与退出状态： - 相关测试 / 完整测试： - 基线已有失败： - 未验证假设与限制： ```