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.
git clone --depth 1 https://github.com/Yoruto/prd-kitWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/rules/yoruto/prd-kit/30-testing)<a href="https://agentmods.dev/rules/yoruto/prd-kit/30-testing"><img src="https://agentmods.dev/badge/rules/yoruto/prd-kit/30-testing/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/rules/yoruto/prd-kit/30-testing"><img src="https://agentmods.dev/badge/rules/yoruto/prd-kit/30-testing.svg" alt="Reviewed on agentmods" width="80" height="20"></a>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.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00000 | $0.01556 |
| Opus 5.5 | $0.00000 | $0.00622 |
| Sonnet 5.5 | $0.00000 | $0.00311 |
| Haiku 4.5 | $0.00000 | $0.00156 |
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 1mo ago.
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.
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 的"
我的核心能力
| 能力 | 说明 |
|---|---|
| 测试策略 | 针对不同风险制定合适的测试策略 |
| 自动化 | 设计和维护高效的自动化测试套件 |
| 风险识别 | 识别潜在的缺陷聚集区和质量风险 |
| 质量门禁 | 设定清晰的质量标准和发布标准 |
| 缺陷分析 | 分析缺陷根因,推动预防改进 |
我的测试理念
- 测试左移 - 越早发现缺陷,修复成本越低
- 风险驱动 - 高风险区域投入更多测试资源
- 自动化优先 - 可自动化的测试尽量自动化
- 数据说话 - 用覆盖率、缺陷密度等指标衡量质量
测试策略框架
测试金字塔
/\
/ \ 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%
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.
- 1mo ago First seen · 213 lines · 0 tokens per session scan A c16d0437158b
30-testing is a cursor rule published in the GitHub repository Yoruto/prd-kit (1 stars, last pushed 28d 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.
Other cursor rules, from other repositories
300-testing
Comprehensive testing guide covering unit, integration, E2E, test frameworks, patterns, and CI/CD integration.
hatch3r-testing
Coverage thresholds, mocking strategy, property-based testing, mutation-score targets, flaky test quarantine, and snapshot test discipline.
testing
Cursor rule "testing" from andersonlemesc/Oryntra, covering testes oryntra, laravel (pest), python (pytest), contract tests (laravel ↔ python) and browser/e2e.
30-testing
Convenciones de testing, cobertura mínima, tipos de tests, mocks.
tester
Tester role - Unit, E2E, and visual regression testing.
go-test
Rules for writing and modifying test files (test.go) in go-crypto-wallet.