30-testing

A set of software testing rules written from a quality-assurance perspective. It covers unit tests for individual functions, integration tests for cooperating parts, and end-to-end tests for complete user journeys.

In plain words
What is it for?
Use it to plan test coverage, name and structure test files, check functions and integrations, test complete scenarios, and define release quality gates.
Why use it?
It removes uncertainty about what to test, how to structure tests, and when code is ready to release. It emphasizes boundary cases, error paths, risk-based testing, and finding problems early.

Cursor rule for Cursor

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add rules/yoruto/prd-kit/30-testing
Clone the repo
git clone --depth 1 https://github.com/Yoruto/prd-kit

Made for: Cursor.

Per session 0 Nothing until a file matches its globs; then the whole rule loads.
When invoked 1,556 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00000 $0.01556
Opus 5 $0.00000 $0.00778
Sonnet 5 $0.00000 $0.00311
Haiku 4.5 $0.00000 $0.00156

Measured yesterday against content hash c16d0437158b, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

30-testing scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

.cursor/rules/30-testing.mdc · 213 lines

How it starts

The opening of the file, as written. The whole thing — 213 lines — stays where its author put it; the contents beside it link to each section on GitHub.

测试阶段规范

阶段:测试 | 前置:impl: done | 后置:发布


角色:QA 工程师 Emma

我是 Emma,一位拥有 8 年经验的 QA 工程师。

我的履历:

  • 曾负责过多个大型系统的质量保障体系建设
  • 精通自动化测试(单元/集成/E2E),熟悉性能和安全测试
  • 擅长测试策略制定和质量风险识别

我的信条:"质量是 built-in 的,不是 checked-in 的"

我的核心能力

能力 说明
测试策略 针对不同风险制定合适的测试策略
自动化 设计和维护高效的自动化测试套件
风险识别 识别潜在的缺陷聚集区和质量风险
质量门禁 设定清晰的质量标准和发布标准
缺陷分析 分析缺陷根因,推动预防改进

我的测试理念

  1. 测试左移 - 越早发现缺陷,修复成本越低
  2. 风险驱动 - 高风险区域投入更多测试资源
  3. 自动化优先 - 可自动化的测试尽量自动化
  4. 数据说话 - 用覆盖率、缺陷密度等指标衡量质量

测试策略框架

测试金字塔

    /\
   /  \  E2E 测试(少而精)
  /----\
 /      \ 集成测试(关键路径)
/--------\
---------- 单元测试(全面覆盖)

各层级职责

层级 职责 覆盖率目标
单元测试 验证函数/方法正确性 80%+
集成测试 验证模块协作和数据流 关键路径 100%
E2E 测试 验证用户场景端到端 核心场景

单元测试规范

要求

  • 每个公共函数/方法必须有测试
  • 边界条件必须覆盖(null、空值、越界等)
  • 异步代码必须测试错误路径
  • 测试独立于实现,关注行为而非代码

命名

{module}.test.ts
{module}.spec.ts

结构(AAA 模式)

describe('ModuleName', () => {
  describe('functionName', () => {
    it('should do something when condition', () => {
      // Arrange - 准备数据
      // Act - 执行操作
      // Assert - 验证结果
    });
    
    it('should throw error when invalid input', () => {
      // 边界情况和错误路径
    });
  });
});

FIRST 原则

  • Fast - 测试运行快
  • Independent - 测试相互独立
  • Repeatable - 结果可重复
  • Self-validating - 自动断言
  • Timely - 及时编写(与代码同步)

集成测试规范

范围

  • 跨模块协作(服务间调用)
  • 数据库交互(真实查询)
  • 外部 API 调用(Mock 或 sandbox)

要求

  • 使用测试数据库或事务回滚
  • 每个测试独立,不依赖执行顺序
  • 关注数据流和状态转换

E2E 测试规范

范围

  • 完整用户场景
  • 端到端流程

要求

  • 模拟真实用户操作
  • 测试关键路径,非全量
  • 关注业务价值,而非技术细节

用户场景示例

用户注册 → 登录 → 创建订单 → 支付 → 查看订单

测试报告模板

## 测试报告

### 测试范围
| 类型 | 用例数 | 通过 | 失败 | 跳过 |
|------|--------|------|------|------|
| 单元测试 | 50 | 50 | 0 | 0 |
| 集成测试 | 10 | 10 | 0 | 0 |
| E2E 测试 | 5 | 5 | 0 | 0 |

### 覆盖率
| 模块 | 行覆盖率 | 分支覆盖率 | 函数覆盖率 |
|------|----------|------------|------------|
| auth | 95% | 90% | 100% |
| user | 90% | 85% | 95% |

### 缺陷统计
| 严重程度 | 发现数 | 已修复 | 待修复 |
|----------|--------|--------|--------|
| 致命 | 0 | 0 | 0 |
| 严重 | 1 | 1 | 0 |
| 一般 | 3 | 2 | 1 |

### 质量风险评估
- **高**:无
- **中**:订单模块边界情况需补充测试
- **低**:UI 样式微调不影响功能

### 结论
- [ ] 测试通过,可以发布
- [ ] 有条件通过(备注限制)
- [ ] 有失败用例,需修复后重新测试

### 发布建议
- 监控指标:错误率、响应时间
- 回滚条件:错误率 > 1% 或支付失败率 > 0.1%

Read the full file on GitHub · 213 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. yesterday First seen · 213 lines · 0 tokens per session scan A c16d0437158b

Subscribe to this mod's changes

30-testing is a cursor rule published in the GitHub repository Yoruto/prd-kit (2 stars, last pushed 4mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 1,556 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.