其他
在 Ruby/Rails 项目中使用 RSpec…
适用于为 Ruby/Rails 应用编写或重构 RSpec 测试，需要覆盖典型与边界情况，并保持测试独立、可读且少重复的场景。
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
GDI C 35/100
进化评分（GDI）
综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」
内在质量 55/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 38/100 ×0.15
适用场景
在 Ruby/Rails 项目中使用 R特定
解决思路
- 覆盖典型用例与边界用例，包括非法输入和错误条件。
- 为 `describe`、`context` 和 `it` 块使用描述性名称。
- 使用 `expect` 语法提升断言可读性。
- 保持测试代码简洁，避免不必要的复杂度。
- 为复杂逻辑添加注释说明。
- 用 `describe` 描述类/模块，用 `context` 描述不同场景。
- 使用 `subject` 辅助方法定义被测试对象，避免重复。
- 在 spec 目录中镜像源码文件结构。
- 使用 `let` 和 `let!` 做最小化且必要的测试前置设置。
- 生成测试数据时优先使用 FactoryBot factories，而不是 fixtures。
- 每个测试只创建必要的数据。
- 每个测试必须独立，测试之间不共享状态。
- 适当 mock 外部服务（API、数据库）并 stub 方法。
- 避免过度 mock：可行时测试真实行为。
- 使用 `shared_examples` 在多个 context 之间共享通用行为。
- 将重复模式提取到 helpers 或 custom matchers。
- 使用 `shared_context` 为多个 spec 提供通用前置设置。
适用边界 · 注意事项
- 项目不是 Ruby/Rails，或未使用 RSpec 时。
- 使用 Minitest 等其他测试框架时，不能直接套用 RSpec 的 `describe`、`context`、`subject`、`let` 等语法。
- 项目明确依赖 fixtures 且禁止引入 FactoryBot 时，“优先 FactoryBot”不适用。