mirror of
https://github.com/lobehub/lobe-chat.git
synced 2026-06-14 03:30:19 +00:00
🐛 fix: desktop local db can't upload image (#8459)
This commit is contained in:
YuTengjing
@@ -1,13 +1,14 @@
|
||||
---
|
||||
description: How to code review
|
||||
globs:
|
||||
globs:
|
||||
alwaysApply: false
|
||||
---
|
||||
|
||||
# Role Description
|
||||
|
||||
- You are a senior full-stack engineer skilled in performance optimization, security, and design systems.
|
||||
- You excel at reviewing code and providing constructive feedback.
|
||||
- Your task is to review submitted Git diffs **in Chinese** and return a structured review report.
|
||||
- You are a senior full-stack engineer skilled in performance optimization, security, and design systems.
|
||||
- You excel at reviewing code and providing constructive feedback.
|
||||
- Your task is to review submitted Git diffs **in Chinese** and return a structured review report.
|
||||
- Review style: concise, direct, focused on what matters most, with actionable suggestions.
|
||||
|
||||
## Before the Review
|
||||
@@ -16,54 +17,57 @@ Gather the modified code and context. Please strictly follow the process below:
|
||||
|
||||
1. Use `read_file` to read [package.json](mdc:package.json)
|
||||
2. Use terminal to run command `git diff HEAD | cat` to obtain the diff and list the changed files. If you recieived empty result, run the same command once more.
|
||||
3. Use `read_file` to open each changed file.
|
||||
4. Use `read_file` to read [rules-attach.mdc](mdc:.cursor/rules/rules-attach.mdc). Even if you think it's unnecessary, you must read it.
|
||||
5. combine changed files, step3 and `agent_requestable_workspace_rules`, list the rules which need to read
|
||||
3. Use `read_file` to open each changed file.
|
||||
4. Use `read_file` to read [rules-attach.mdc](mdc:.cursor/rules/rules-attach.mdc). Even if you think it's unnecessary, you must read it.
|
||||
5. combine changed files, step3 and `agent_requestable_workspace_rules`, list the rules which need to read
|
||||
6. Use `read_file` to read the rules list in step 5
|
||||
|
||||
## Review
|
||||
|
||||
### Code Style
|
||||
|
||||
- Ensure JSDoc comments accurately reflect the implementation; update them when needed.
|
||||
- Look for opportunities to simplify or modernize code with the latest JavaScript/TypeScript features.
|
||||
- Prefer `async`/`await` over callbacks or chained `.then` promises.
|
||||
- Use consistent, descriptive naming—avoid obscure abbreviations.
|
||||
- Replace magic numbers or strings with well-named constants.
|
||||
- Ensure JSDoc comments accurately reflect the implementation; update them when needed.
|
||||
- Look for opportunities to simplify or modernize code with the latest JavaScript/TypeScript features.
|
||||
- Prefer `async`/`await` over callbacks or chained `.then` promises.
|
||||
- Use consistent, descriptive naming—avoid obscure abbreviations.
|
||||
- Replace magic numbers or strings with well-named constants.
|
||||
- Use semantically meaningful variable, function, and class names.
|
||||
- Ignore purely formatting issues and other autofixable lint problems.
|
||||
|
||||
### Code Optimization
|
||||
|
||||
- Prefer `for…of` loops to index-based `for` loops when feasible.
|
||||
- Decide whether callbacks should be **debounced** or **throttled**.
|
||||
- Use components from `@lobehub/ui`, Ant Design, or the existing design system instead of raw HTML tags (e.g., `Button` vs. `button`).
|
||||
- reuse npm packages already installed (e.g., `lodash/omit`) rather than reinventing the wheel.
|
||||
- Design for dark mode and mobile responsiveness:
|
||||
- Use the `antd-style` token system instead of hard-coded colors.
|
||||
- Select the proper component variants.
|
||||
- Performance considerations:
|
||||
- Where safe, convert sequential async flows to concurrent ones with `Promise.all`, `Promise.race`, etc.
|
||||
- Prefer `for…of` loops to index-based `for` loops when feasible.
|
||||
- Decide whether callbacks should be **debounced** or **throttled**.
|
||||
- Use components from `@lobehub/ui`, Ant Design, or the existing design system instead of raw HTML tags (e.g., `Button` vs. `button`).
|
||||
- reuse npm packages already installed (e.g., `lodash/omit`) rather than reinventing the wheel.
|
||||
- Design for dark mode and mobile responsiveness:
|
||||
- Use the `antd-style` token system instead of hard-coded colors.
|
||||
- Select the proper component variants.
|
||||
- Performance considerations:
|
||||
- Where safe, convert sequential async flows to concurrent ones with `Promise.all`, `Promise.race`, etc.
|
||||
- Query only the required columns from a database rather than selecting entire rows.
|
||||
|
||||
### Obvious Bugs
|
||||
|
||||
- Do not silently swallow errors in `catch` blocks; at minimum, log them.
|
||||
- Revert temporary code used only for testing (e.g., debug logs, temporary configs).
|
||||
- Remove empty handlers (e.g., an empty `onClick`).
|
||||
- Do not silently swallow errors in `catch` blocks; at minimum, log them.
|
||||
- Revert temporary code used only for testing (e.g., debug logs, temporary configs).
|
||||
- Remove empty handlers (e.g., an empty `onClick`).
|
||||
- Confirm the UI degrades gracefully for unauthenticated users.
|
||||
- Don't leave any debug logs in the code (except when using the `debug` module properly).
|
||||
- When using the `debug` module, avoid `import { log } from 'debug'` as it logs directly to console. Use proper debug namespaces instead.
|
||||
- Check logs for sensitive information like api key, etc
|
||||
|
||||
## After the Review: output
|
||||
|
||||
1. Summary
|
||||
- Start with a brief explanation of what the change set does.
|
||||
- Summarize the changes for each modified file (or logical group).
|
||||
- Start with a brief explanation of what the change set does.
|
||||
- Summarize the changes for each modified file (or logical group).
|
||||
2. Comments Issues
|
||||
- List the most critical issues first.
|
||||
- Use an ordered list, which will be convenient for me to reference later.
|
||||
- For each issue:
|
||||
- Mark severity tag (`❌ Must fix`, `⚠️ Should fix`, `💅 Nitpick`)
|
||||
- Provode file path to the relevant file.
|
||||
- Provide recommended fix
|
||||
- End with a **git commit** command, instruct the author to run it.
|
||||
- We use gitmoji to label commit messages, format: [emoji] <type>(<scope>): <subject>
|
||||
- List the most critical issues first.
|
||||
- Use an ordered list, which will be convenient for me to reference later.
|
||||
- For each issue:
|
||||
- Mark severity tag (`❌ Must fix`, `⚠️ Should fix`, `💅 Nitpick`)
|
||||
- Provode file path to the relevant file.
|
||||
- Provide recommended fix
|
||||
- End with a **git commit** command, instruct the author to run it.
|
||||
- We use gitmoji to label commit messages, format: [emoji] <type>(<scope>): <subject>
|
||||
|
||||
@@ -1,8 +1,9 @@
|
||||
---
|
||||
description:
|
||||
globs:
|
||||
description:
|
||||
globs:
|
||||
alwaysApply: true
|
||||
---
|
||||
|
||||
## System Role
|
||||
|
||||
You are an expert in full-stack Web development, proficient in JavaScript, TypeScript, CSS, React, Node.js, Next.js, Postgresql, all kinds of network protocols.
|
||||
@@ -11,7 +12,6 @@ You are an expert in LLM and Ai art. In Ai image generation, you are proficient
|
||||
|
||||
You are an expert in UI/UX design, proficient in web interaction patterns, responsive design, accessibility, and user behavior optimization. You excel at improving user retention and paid conversion rates through various interaction details.
|
||||
|
||||
|
||||
## Problem Solving
|
||||
|
||||
- Before formulating any response, you must first gather context by using tools like codebase_search, grep_search, file_search, web_search, fetch_rules, context7, and read_file to avoid making assumptions.
|
||||
@@ -36,3 +36,8 @@ You are an expert in UI/UX design, proficient in web interaction patterns, respo
|
||||
- If you're unable to access or retrieve content from websites, please inform me immediately and request the specific information needed rather than making assumptions
|
||||
- You can use emojis, npm packages like `chalk`/`chalk-animation`/`terminal-link`/`gradient-string`/`log-symbols`/`boxen`/`consola`/`@clack/prompts` to create beautiful terminal output
|
||||
- Don't run `tsc --noEmit` to check ts syntax error, because our project is very large and the validate very slow
|
||||
|
||||
## Some logging rules
|
||||
|
||||
- Never log user private information like api key, etc
|
||||
- Don't use `import { log } from 'debug'` to log messages, because it will directly log the message to the console.
|
||||
|
||||
@@ -28,85 +28,39 @@ LobeChat 项目使用 Vitest 测试库，配置了两种不同的测试环境：
|
||||
|
||||
## 🚀 测试运行命令
|
||||
|
||||
### package.json 脚本说明
|
||||
**🚨 性能警告**: 项目包含 3000+ 测试用例，完整运行需要约 10 分钟。务必使用文件过滤或测试名称过滤。
|
||||
|
||||
查看 [package.json](mdc:package.json) 中的测试相关脚本：
|
||||
|
||||
```json
|
||||
{
|
||||
"test": "npm run test-app && npm run test-server",
|
||||
"test-app": "vitest run --config vitest.config.ts",
|
||||
"test-app:coverage": "vitest run --config vitest.config.ts --coverage",
|
||||
"test-server": "vitest run --config vitest.config.server.ts",
|
||||
"test-server:coverage": "vitest run --config vitest.config.server.ts --coverage"
|
||||
}
|
||||
```
|
||||
|
||||
### 推荐的测试运行方式
|
||||
|
||||
#### ⚠️ 重要提醒
|
||||
|
||||
**🚨 性能警告**:
|
||||
|
||||
- **永远不要直接运行整个项目的所有测试用例** - 项目包含 3000+ 测试用例，完整运行需要约 10 分钟
|
||||
- **务必使用文件过滤或测试名称过滤** - 始终指定具体的测试文件或测试名称模式
|
||||
- **避免无意中触发全量测试** - 某些看似针对单个文件的命令实际上会运行所有测试
|
||||
|
||||
#### ✅ 正确的命令格式
|
||||
### ✅ 正确的命令格式
|
||||
|
||||
```bash
|
||||
# 运行所有客户端测试
|
||||
npx vitest run --config vitest.config.ts
|
||||
|
||||
# 运行所有服务端测试
|
||||
npx vitest run --config vitest.config.server.ts
|
||||
# 运行所有客户端/服务端测试
|
||||
npx vitest run --config vitest.config.ts # 客户端测试
|
||||
npx vitest run --config vitest.config.server.ts # 服务端测试
|
||||
|
||||
# 运行特定测试文件 (支持模糊匹配)
|
||||
npx vitest run --config vitest.config.ts basic
|
||||
npx vitest run --config vitest.config.ts user.test.ts
|
||||
|
||||
# 运行特定文件的特定行号
|
||||
npx vitest run --config vitest.config.ts src/utils/helper.test.ts:25
|
||||
npx vitest run --config vitest.config.ts basic/foo.test.ts:10,basic/foo.test.ts:25
|
||||
|
||||
# 过滤特定测试用例名称
|
||||
npx vitest -t "test case name" --config vitest.config.ts
|
||||
# 运行特定测试用例名称 (使用 -t 参数)
|
||||
npx vitest run --config vitest.config.ts -t "test case name"
|
||||
|
||||
# 组合使用文件和测试名称过滤
|
||||
npx vitest run --config vitest.config.ts filename.test.ts -t "specific test"
|
||||
|
||||
# 生成覆盖率报告 (使用 --coverage 参数)
|
||||
npx vitest run --config vitest.config.ts --coverage
|
||||
```
|
||||
|
||||
#### ❌ 避免的命令格式
|
||||
### ❌ 避免的命令格式
|
||||
|
||||
```bash
|
||||
# ❌ 这些命令会运行所有 3000+ 测试用例，耗时约 10 分钟！
|
||||
npm test
|
||||
npm run test
|
||||
pnpm test
|
||||
pnpm run test
|
||||
|
||||
# ❌ 这些命令看似针对单个文件，但实际会运行所有测试用例！, 需要直接运行 vitest 命令不要使用 test npm script
|
||||
npm test src/libs/model-runtime/utils/openaiCompatibleFactory/index.test.ts
|
||||
pnpm test src/components/Button/index.test.tsx
|
||||
|
||||
# ❌ 不要使用 pnpm test xxx (这不是有效的 vitest 命令)
|
||||
pnpm test some-file
|
||||
npm test some-file.test.ts
|
||||
|
||||
# ❌ 不要使用裸 vitest (会进入 watch 模式)
|
||||
vitest test-file.test.ts
|
||||
|
||||
# ❌ 不要混淆测试环境
|
||||
npx vitest run --config vitest.config.server.ts client-component.test.ts
|
||||
```
|
||||
|
||||
### 关键运行参数说明
|
||||
|
||||
- **`vitest run`**: 运行一次测试然后退出 (避免 watch 模式)
|
||||
- **`vitest`**: 默认进入 watch 模式，持续监听文件变化
|
||||
- **`--config`**: 指定配置文件，选择正确的测试环境
|
||||
- **`-t`**: 过滤测试用例名称，支持正则表达式
|
||||
- **`--coverage`**: 生成测试覆盖率报告
|
||||
|
||||
## 🔧 测试修复原则
|
||||
|
||||
### 核心原则 ⚠️
|
||||
@@ -116,45 +70,124 @@ npx vitest run --config vitest.config.server.ts client-component.test.ts
|
||||
3. **专注单一问题**: 只修复指定的测试，不要添加额外测试或功能
|
||||
4. **不自作主张**: 不要因为发现其他问题就直接修改，先提出再讨论
|
||||
|
||||
### 测试协作最佳实践 🤝
|
||||
|
||||
基于实际开发经验总结的重要协作原则：
|
||||
|
||||
#### 1. 失败处理策略
|
||||
|
||||
**核心原则**: 避免盲目重试，快速识别问题并寻求帮助。
|
||||
|
||||
- **失败阈值**: 当连续尝试修复测试 1-2 次都失败后，应立即停止继续尝试
|
||||
- **问题总结**: 分析失败原因，整理已尝试的解决方案及其失败原因
|
||||
- **寻求帮助**: 带着清晰的问题摘要和尝试记录向团队寻求帮助
|
||||
- **避免陷阱**: 不要陷入"不断尝试相同或类似方法"的循环
|
||||
|
||||
```typescript
|
||||
// ❌ 错误做法：连续失败后继续盲目尝试
|
||||
// 第3次、第4次仍在用相似的方法修复同一个问题
|
||||
|
||||
// ✅ 正确做法：失败1-2次后总结问题
|
||||
/*
|
||||
问题总结：
|
||||
1. 尝试过的方法：修改 mock 数据结构
|
||||
2. 失败原因：仍然提示类型不匹配
|
||||
3. 具体错误：Expected 'UserData' but received 'UserProfile'
|
||||
4. 需要帮助：不确定最新的 UserData 接口定义
|
||||
*/
|
||||
```
|
||||
|
||||
#### 2. 测试用例命名规范
|
||||
|
||||
**核心原则**: 测试应该关注"行为"，而不是"实现细节"。
|
||||
|
||||
- **描述业务场景**: `describe` 和 `it` 的标题应该描述具体的业务场景和预期行为
|
||||
- **避免实现绑定**: 不要在测试名称中提及具体的代码行号、覆盖率目标或实现细节
|
||||
- **保持稳定性**: 测试名称应该在代码重构后仍然有意义
|
||||
|
||||
```typescript
|
||||
// ❌ 错误的测试命名
|
||||
describe('User component coverage', () => {
|
||||
it('covers line 45-50 in getUserData', () => {
|
||||
// 为了覆盖第45-50行而写的测试
|
||||
});
|
||||
|
||||
it('tests the else branch', () => {
|
||||
// 仅为了测试某个分支而存在
|
||||
});
|
||||
});
|
||||
|
||||
// ✅ 正确的测试命名
|
||||
describe('<UserAvatar />', () => {
|
||||
it('should render fallback icon when image url is not provided', () => {
|
||||
// 测试具体的业务场景，自然会覆盖相关代码分支
|
||||
});
|
||||
|
||||
it('should display user initials when avatar image fails to load', () => {
|
||||
// 描述用户行为和预期结果
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
**覆盖率提升的正确思路**:
|
||||
|
||||
- ✅ 通过设计各种业务场景（正常流程、边缘情况、错误处理）来自然提升覆盖率
|
||||
- ❌ 不要为了达到覆盖率数字而写测试，更不要在测试中注释"为了覆盖 xxx 行"
|
||||
|
||||
#### 3. 测试组织结构
|
||||
|
||||
**核心原则**: 维护清晰的测试层次结构，避免冗余的顶级测试块。
|
||||
|
||||
- **复用现有结构**: 添加新测试时，优先在现有的 `describe` 块中寻找合适的位置
|
||||
- **逻辑分组**: 相关的测试用例应该组织在同一个 `describe` 块内
|
||||
- **避免碎片化**: 不要为了单个测试用例就创建新的顶级 `describe` 块
|
||||
|
||||
```typescript
|
||||
// ❌ 错误的组织方式：创建过多顶级块
|
||||
describe('<UserProfile />', () => {
|
||||
it('should render user name', () => {});
|
||||
});
|
||||
|
||||
describe('UserProfile new prop test', () => {
|
||||
// 不必要的新块
|
||||
it('should handle email display', () => {});
|
||||
});
|
||||
|
||||
describe('UserProfile edge cases', () => {
|
||||
// 不必要的新块
|
||||
it('should handle missing avatar', () => {});
|
||||
});
|
||||
|
||||
// ✅ 正确的组织方式：合并相关测试
|
||||
describe('<UserProfile />', () => {
|
||||
it('should render user name', () => {});
|
||||
|
||||
it('should handle email display', () => {});
|
||||
|
||||
it('should handle missing avatar', () => {});
|
||||
|
||||
describe('when user data is incomplete', () => {
|
||||
// 只有在有多个相关子场景时才创建子组
|
||||
it('should show placeholder for missing name', () => {});
|
||||
it('should hide email section when email is undefined', () => {});
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
**组织决策流程**:
|
||||
|
||||
1. 是否存在逻辑相关的现有 `describe` 块？ → 如果有，添加到其中
|
||||
2. 是否有多个（3个以上）相关的测试用例？ → 如果有，可以考虑创建新的子 `describe`
|
||||
3. 是否是独立的、无关联的功能模块？ → 如果是，才考虑创建新的顶级 `describe`
|
||||
|
||||
### 测试修复流程
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
subgraph "阶段一：分析与复现"
|
||||
A[开始：收到测试失败报告] --> B[定位并运行失败的测试];
|
||||
B --> C{是否能在本地复现?};
|
||||
C -->|否| D[检查测试环境/配置/依赖];
|
||||
C -->|是| E[分析：阅读测试代码、错误日志、Git 历史];
|
||||
end
|
||||
|
||||
subgraph "阶段二：诊断与调试"
|
||||
E --> F[建立假设：问题出在测试、代码还是环境?];
|
||||
F --> G["调试：使用 console.log 或 debugger 深入检查"];
|
||||
G --> H{假设是否被证实?};
|
||||
H -->|否, 重新假设| F;
|
||||
end
|
||||
|
||||
subgraph "阶段三：修复与验证"
|
||||
H -->|是| I{确定根本原因};
|
||||
I -->|测试逻辑错误| J[修复测试代码];
|
||||
I -->|实现代码 Bug| K[修复实现代码];
|
||||
I -->|环境/配置问题| L[修复配置或依赖];
|
||||
J --> M[验证修复：重新运行失败的测试];
|
||||
K --> M;
|
||||
L --> M;
|
||||
M --> N{测试是否通过?};
|
||||
N -->|否, 修复无效| F;
|
||||
N -->|是| O[扩大验证：运行当前文件内所有测试];
|
||||
O --> P{是否全部通过?};
|
||||
P -->|否, 引入新问题| F;
|
||||
end
|
||||
|
||||
subgraph "阶段四：总结"
|
||||
P -->|是| Q[完成：撰写修复总结];
|
||||
end
|
||||
|
||||
D --> F;
|
||||
```
|
||||
1. **复现问题**: 定位并运行失败的测试，确认能在本地复现
|
||||
2. **分析原因**: 阅读测试代码、错误日志和相关文件的 Git 修改历史
|
||||
3. **建立假设**: 判断问题出在测试逻辑、实现代码还是环境配置
|
||||
4. **修复验证**: 根据假设进行修复，重新运行测试确认通过
|
||||
5. **扩大验证**: 运行当前文件内所有测试，确保没有引入新问题
|
||||
6. **撰写总结**: 说明错误原因和修复方法
|
||||
|
||||
### 修复完成后的总结
|
||||
|
||||
@@ -197,7 +230,7 @@ flowchart TD
|
||||
|
||||
例如：
|
||||
|
||||
```
|
||||
```plaintext
|
||||
src/components/Button/
|
||||
├── index.tsx # 源文件
|
||||
└── index.test.tsx # 测试文件
|
||||
@@ -205,13 +238,12 @@ src/components/Button/
|
||||
|
||||
## 🛠️ 测试调试技巧
|
||||
|
||||
### 运行失败测试的步骤
|
||||
### 测试调试步骤
|
||||
|
||||
1. **确定测试类型**: 查看文件路径确定使用哪个配置
|
||||
2. **运行单个测试**: 使用 `-t` 参数隔离问题
|
||||
3. **检查错误日志**: 仔细阅读错误信息和堆栈跟踪
|
||||
4. **查看最近修改记录**: 检查相关文件的最近变更情况
|
||||
5. **添加调试日志**: 在测试中添加 `console.log` 了解执行流程
|
||||
1. **确定测试环境**: 根据文件路径选择正确的配置文件
|
||||
2. **隔离问题**: 使用 `-t` 参数只运行失败的测试用例
|
||||
3. **分析错误**: 仔细阅读错误信息、堆栈跟踪和最近的文件修改记录
|
||||
4. **添加调试**: 在测试中添加 `console.log` 了解执行流程
|
||||
|
||||
### TypeScript 类型处理 📝
|
||||
|
||||
@@ -245,157 +277,47 @@ mockStream.toReadableStream = () => mockStream;
|
||||
|
||||
### 检查最近修改记录 🔍
|
||||
|
||||
为了更好地判断测试失败的根本原因，需要**系统性地检查相关文件的修改历史**。这是问题定位的关键步骤。
|
||||
系统性地检查相关文件的修改历史是问题定位的关键步骤。
|
||||
|
||||
#### 第一步：确定需要检查的文件范围
|
||||
#### 三步检查法
|
||||
|
||||
1. **测试文件本身**: `path/to/component.test.ts`
|
||||
2. **对应的实现文件**: `path/to/component.ts` 或 `path/to/component/index.ts`
|
||||
3. **相关依赖文件**: 测试或实现中导入的其他模块
|
||||
|
||||
#### 第二步：检查当前工作目录状态
|
||||
**Step 1: 查看当前状态**
|
||||
|
||||
```bash
|
||||
# 查看所有未提交的修改状态
|
||||
git status
|
||||
|
||||
# 重点关注测试文件和实现文件是否有未提交的修改
|
||||
git status | grep -E "(test|spec)"
|
||||
git status # 查看未提交的修改
|
||||
git diff path/to/component.test.ts | cat # 查看测试文件修改
|
||||
git diff path/to/component.ts | cat # 查看实现文件修改
|
||||
```
|
||||
|
||||
#### 第三步：检查未提交的修改内容
|
||||
**Step 2: 查看提交历史**
|
||||
|
||||
```bash
|
||||
# 查看测试文件的未提交修改 (工作区 vs 暂存区)
|
||||
git diff path/to/component.test.ts | cat
|
||||
|
||||
# 查看对应实现文件的未提交修改
|
||||
git diff path/to/component.ts | cat
|
||||
|
||||
# 查看已暂存但未提交的修改
|
||||
git diff --cached path/to/component.test.ts | cat
|
||||
git diff --cached path/to/component.ts | cat
|
||||
git log --pretty=format:"%h %ad %s" --date=relative -3 path/to/component.ts | cat
|
||||
```
|
||||
|
||||
#### 第四步：检查提交历史和时间相关性
|
||||
|
||||
**首先查看提交时间，判断修改的时效性**：
|
||||
**Step 3: 查看具体修改内容**
|
||||
|
||||
```bash
|
||||
# 查看测试文件的最近提交历史，包含提交时间
|
||||
git log --pretty=format:"%h %ad %s" --date=relative -5 path/to/component.test.ts | cat
|
||||
|
||||
# 查看实现文件的最近提交历史，包含提交时间
|
||||
git log --pretty=format:"%h %ad %s" --date=relative -5 path/to/component.ts | cat
|
||||
|
||||
# 查看详细的提交时间（ISO格式，便于精确判断）
|
||||
git log --pretty=format:"%h %ad %an %s" --date=iso -3 path/to/component.ts | cat
|
||||
git log --pretty=format:"%h %ad %an %s" --date=iso -3 path/to/component.test.ts | cat
|
||||
git show HEAD -- path/to/component.ts | cat # 查看最新提交的修改
|
||||
```
|
||||
|
||||
**判断提交的参考价值**：
|
||||
#### 时间相关性判断
|
||||
|
||||
1. **最近提交（24小时内）**: 🔴 **高度相关** - 很可能是导致测试失败的直接原因
|
||||
2. **近期提交（1-7天内）**: 🟡 **中等相关** - 可能相关，需要仔细分析修改内容
|
||||
3. **较早提交（超过1周）**: ⚪ **低相关性** - 除非是重大重构，否则不太可能是直接原因
|
||||
|
||||
#### 第五步：基于时间相关性查看具体修改内容
|
||||
|
||||
**根据提交时间的远近，优先查看最近的修改**：
|
||||
|
||||
```bash
|
||||
# 如果有24小时内的提交，重点查看这些修改
|
||||
git show HEAD -- path/to/component.test.ts | cat
|
||||
git show HEAD -- path/to/component.ts | cat
|
||||
|
||||
# 查看次新的提交（如果最新提交时间较远）
|
||||
git show HEAD~1 -- path/to/component.ts | cat
|
||||
git show path/to/component.ts < recent-commit-hash > -- | cat
|
||||
|
||||
# 对比最近两次提交的差异
|
||||
git diff HEAD~1 HEAD -- path/to/component.ts | cat
|
||||
```
|
||||
|
||||
#### 第六步：分析修改与测试失败的关系
|
||||
|
||||
基于修改记录和时间相关性判断：
|
||||
|
||||
1. **最近修改了实现代码**:
|
||||
|
||||
```bash
|
||||
# 重点检查实现逻辑的变化
|
||||
git diff HEAD~1 path/to/component.ts | cat
|
||||
```
|
||||
|
||||
- 很可能是实现代码的变更导致测试失败
|
||||
- 检查实现逻辑是否正确
|
||||
- 确认测试是否需要相应更新
|
||||
|
||||
2. **最近修改了测试代码**:
|
||||
|
||||
```bash
|
||||
# 重点检查测试逻辑的变化
|
||||
git diff HEAD~1 path/to/component.test.ts | cat
|
||||
```
|
||||
|
||||
- 可能是测试本身写错了
|
||||
- 检查测试逻辑和断言是否正确
|
||||
- 确认测试是否符合实现的预期行为
|
||||
|
||||
3. **两者都有最近修改**:
|
||||
|
||||
```bash
|
||||
# 对比两个文件的修改时间
|
||||
git log --pretty=format:"%ad %f" --date=iso -1 path/to/component.ts | cat
|
||||
git log --pretty=format:"%ad %f" --date=iso -1 path/to/component.test.ts | cat
|
||||
```
|
||||
|
||||
- 需要综合分析两者的修改
|
||||
- 确定哪个修改更可能导致问题
|
||||
- 优先检查时间更近的修改
|
||||
|
||||
4. **都没有最近修改**:
|
||||
- 可能是依赖变更或环境问题
|
||||
- 检查 `package.json`、配置文件等的修改
|
||||
- 查看是否有全局性的代码重构
|
||||
|
||||
#### 修改记录检查示例
|
||||
|
||||
```bash
|
||||
# 完整的检查流程示例
|
||||
echo "=== 检查文件修改状态 ==="
|
||||
git status | grep component
|
||||
|
||||
echo "=== 检查未提交修改 ==="
|
||||
git diff src/components/Button/index.test.tsx | cat
|
||||
git diff src/components/Button/index.tsx | cat
|
||||
|
||||
echo "=== 检查提交历史和时间 ==="
|
||||
git log --pretty=format:"%h %ad %s" --date=relative -3 src/components/Button/index.test.tsx | cat
|
||||
git log --pretty=format:"%h %ad %s" --date=relative -3 src/components/Button/index.tsx | cat
|
||||
|
||||
echo "=== 根据时间优先级查看修改内容 ==="
|
||||
# 如果有24小时内的提交，重点查看
|
||||
git show HEAD -- src/components/Button/index.tsx | cat
|
||||
```
|
||||
- **24小时内的提交**: 🔴 **高度相关** - 很可能是直接原因
|
||||
- **1-7天内的提交**: 🟡 **中等相关** - 需要仔细分析
|
||||
- **超过1周的提交**: ⚪ **低相关性** - 除非重大重构
|
||||
|
||||
## 特殊场景的测试
|
||||
|
||||
针对一些特殊场景的测试，需要阅读相关文件：
|
||||
针对一些特殊场景的测试，需要阅读相关 rules：
|
||||
|
||||
- [Electron IPC 接口测试策略](mdc:./electron-ipc-test.mdc)
|
||||
- [数据库 Model 测试指南](mdc:./db-model-test.mdc)
|
||||
|
||||
## 🎯 总结
|
||||
## 🎯 核心要点
|
||||
|
||||
修复测试时，记住以下关键点：
|
||||
|
||||
- **使用正确的命令**: `npx vitest run --config [config-file]`
|
||||
- **理解测试意图**: 先读懂测试再修复
|
||||
- **查看最近修改**: 检查相关文件的 git 修改记录，判断问题根源
|
||||
- **选择正确环境**: 客户端测试用 `vitest.config.ts`，服务端用 `vitest.config.server.ts`
|
||||
- **专注单一问题**: 只修复当前的测试失败
|
||||
- **验证修复结果**: 确保修复后测试通过且无副作用
|
||||
- **提供修复总结**: 说明错误原因和修复方法
|
||||
- **Model 测试安全第一**: 必须包含用户权限检查和对应的安全测试
|
||||
- **Model 双环境验证**: 必须在 PGLite 和 PostgreSQL 两个环境下都验证通过
|
||||
- **命令格式**: 使用 `npx vitest run --config [config-file]` 并指定文件过滤
|
||||
- **修复原则**: 失败1-2次后寻求帮助，测试命名关注行为而非实现细节
|
||||
- **调试流程**: 复现 → 分析 → 假设 → 修复 → 验证 → 总结
|
||||
- **文件组织**: 优先在现有 `describe` 块中添加测试，避免创建冗余顶级块
|
||||
- **安全要求**: Model 测试必须包含权限检查，并在双环境下验证通过
|
||||
|
||||
Reference in New Issue
Block a user