用途：引导 Red-Green-Refactor 测试驱动开发循环——编写描述期望行为的失败测试，实现最小代码使其通过，随后在测试保持通过的情况下改进代码。详细代码示例、常见模式与反模式见 references/testing-patterns.md。
测试类型选择：Model spec 用于验证、作用域、实例方法，位于 spec/models/；Request spec 用于 API 端点、HTTP 响应，位于 spec/requests/；System spec 用于带 JavaScript 的完整用户流程，位于 spec/system/；Service spec 用于业务逻辑与复杂操作，位于 spec/services/；Job spec 用于后台任务行为，位于 spec/jobs/。
工作流步骤：需求分析——编写代码前明确预期输入、输出、边界情况与错误处理，需求不明确时应提问；选择测试类型——根据被测对象从上表选取合适的 spec 类型；编写失败 spec（RED）——编写描述期望行为的 spec，遵循 references 文件中的结构模板；验证失败——运行 bundle exec rspec path/to/spec.rb --format documentation，spec 必须以清晰信息失败，若立即通过则说明行为已存在或 spec 有误；实现最小代码（GREEN）——编写使 spec 通过的最小代码，不做优化、不处理额外边界、暂不重构；验证通过——再次运行 spec，必须通过，若失败应阅读错误并修复实现（而非 spec，除非 spec 本身有误）后重跑；重构——每次只做一处改动：提取方法、改善命名、消除重复、简化逻辑，每次改动后运行 spec，失败则撤销；最终验证——运行所有相关 spec，全部通过，若有失败则撤销近期改动并尝试其他方式。
良好 spec 特征：每个 example 只测一个行为；描述清晰，用 describe/context 读起来像句子；最小化 setup，只创建特定测试所需数据；执行快，优先 build 而非 create，mock 外部服务；相互独立，不依赖顺序或共享状态。
重构目标：将长方法提取为更小的聚焦方法；将不清晰的命名改为揭示意图的命名；将重复代码消除为共享抽象；将复杂条件简化为更清晰模式。重构规则：每次只做一处改动；每次改动后运行 spec；若 spec 失败则撤销并尝试其他方式；代码整洁即停止，不要过度设计。
限制：面向 Rails/RSpec 测试环境；具体安装与配置方式暂未提供。