tests-new

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

New Tests for Recent Work

近期开发功能的新增测试

Review recent changes and add missing test coverage where it matters.

检查最近的代码变更，为核心业务逻辑补充缺失的测试覆盖。

Instructions

使用说明

Step 1: Identify Recent Changes

步骤1：识别近期变更

Run

git diff HEAD~1

(or

git diff main...HEAD

if on a branch) to find what changed. If no git changes, ask the user which files to cover.

Focus on:

New functions, methods, or components
Changed behavior in existing code
New API endpoints or routes
Modified business logic

运行

git diff HEAD~1

（如果在开发分支上可使用

git diff main...HEAD

）查找变更内容。如果没有git变更记录，询问用户需要覆盖哪些文件。

重点关注：

新增的函数、方法或组件
现有代码中被修改的行为
新增的API端点或路由
被修改的业务逻辑

Step 2: Audit Existing Coverage

步骤2：审计现有测试覆盖

For each changed file, check if corresponding tests exist:

src/foo.ts

→ look for

src/foo.test.ts

tests/foo.test.ts

__tests__/foo.test.ts

Follow the project's test file convention

Classify each changed function/component:

Status	Meaning
Untested	No test file or no tests for this function
Under-tested	Tests exist but miss important paths
Covered	Tests adequately cover the behavior

针对每个变更文件，检查是否存在对应的测试文件：

src/foo.ts

→ 查找

src/foo.test.ts

、

tests/foo.test.ts

、

__tests__/foo.test.ts

遵循项目的测试文件命名规范

对每个变更的函数/组件进行分类：

状态	含义
未测试	不存在测试文件，或该函数没有对应测试用例
测试不足	已有测试，但遗漏了重要的代码路径
覆盖完整	测试已充分覆盖相关业务行为

Step 3: Prioritize by Risk

步骤3：按风险优先级排序

Don't test everything — test what matters. Prioritize:

Complex logic — conditionals, loops, state machines, calculations
Error paths — what happens when things fail
Data transformations — parsing, formatting, mapping
Integration boundaries — API calls, database queries, external services
User-facing behavior — things that break the experience if wrong

Skip:

Simple getters/setters
Pure pass-through functions
Framework boilerplate
Code that's already well-covered

无需测试所有内容，仅测试核心业务逻辑。优先级排序：

复杂逻辑 —— 条件判断、循环、状态机、计算逻辑
错误路径 —— 异常场景下的处理逻辑
数据转换 —— 解析、格式化、映射逻辑
集成边界 —— API调用、数据库查询、外部服务交互
用户可见行为 —— 出错会直接影响用户体验的逻辑

跳过以下内容：

简单的getters/setters
纯透传函数
框架样板代码
已具备充分测试覆盖的代码

Step 4: Write Tests

步骤4：编写测试用例

Follow the project's existing test patterns (framework, assertion style, file structure, mocking approach). Read 1-2 existing test files first to match conventions.

For each test:

Name describes behavior, not implementation:

"returns empty array when no results found"

not

"test getResults"

Arrange-Act-Assert structure
One behavior per test — if a test name has "and", split it
Real edge cases: empty input, null/undefined, boundary values, concurrent access, error responses

遵循项目现有的测试模式（测试框架、断言风格、文件结构、mock方案）。先阅读1-2个现有测试文件，确保符合项目规范。

每个测试用例需满足：

名称描述业务行为，而非实现细节：比如
```
"returns empty array when no results found"
```
，而非
```
"test getResults"
```
采用 Arrange-Act-Assert 结构
每个测试仅覆盖一个行为 —— 如果测试名称中包含“和/and”，拆分该测试
覆盖真实边界用例：空输入、null/undefined、边界值、并发访问、错误响应

Step 5: Verify

步骤5：验证测试

Run the new tests to ensure they pass. If any fail, that's a potential bug — flag it rather than deleting the test.

运行新增的测试用例，确保全部通过。如果有测试失败，说明可能存在潜在bug——标记该问题，不要直接删除测试用例。

Step 6: Report

步骤6：输出报告

undefined

undefined

New Test Coverage

新增测试覆盖

Files analyzed: [count] Tests added: [count] Potential bugs found: [count, if any]

已分析文件数： [count] 新增测试数： [count] 发现潜在bug数： [count, if any]

Added

已补充覆盖

```
[test file]
```
: [what behaviors are now covered]

```
[test file]
```
: [当前覆盖的业务行为]

Skipped (adequate coverage)

已跳过（覆盖充足）

```
[file]
```
: already covered by [test file]

```
[file]
```
: 已被 [test file] 覆盖

Potential Bugs

潜在bug

```
[test name]
```
: expected [X] but got [Y] — [file:line]

undefined

```
[test name]
```
: 预期 [X] 但得到 [Y] —— [file:line]

undefined