Files
yys-editor/docs/testing-rules.md
rookie4show 9227a61c85 fix: 修复保存后刷新网页图层全变成1的问题
问题原因:
1. LogicFlow 的 render() 方法不会自动应用节点的 zIndex 属性
2. 切换标签时,LogicFlow Label 插件对空 _label 数组处理有误导致渲染失败
3. 渲染失败后节点 zIndex 被重置为默认值 1

解决方案:
1. 在 App.vue 中,render() 后立即从保存的数据中恢复每个节点的 zIndex
2. 在 normalizeGraphData() 中清理空的 _label 数组,避免 Label 插件报错
3. 简化 FlowEditor.vue 中的 normalizeAllNodes(),移除不必要的重新分配逻辑
4. 清理调试日志,保持代码整洁

测试:
- 添加节点并调整图层顺序
- 切换标签页
- 刷新浏览器
- 确认图层顺序保持不变
2026-02-13 19:28:21 +08:00

3.9 KiB
Raw Blame History

测试规范

核心原则

所有涉及数据层和业务逻辑的改动,必须在提交前通过测试验证。

必须编写测试的场景

1. 数据模型变更

  • 修改 schema.ts 中的类型定义
  • 添加新的数据结构或接口
  • 修改默认值配置

要求: 在 schema.test.ts 中添加对应测试用例

2. Store 状态管理

  • 修改 useStore.ts 中的任何方法
  • 添加新的状态管理逻辑
  • 修改文件操作(增删改查)

要求: 在 useStore.test.ts 中添加对应测试用例

3. 核心业务逻辑

  • 数据导入导出功能
  • 数据迁移和兼容性处理
  • localStorage 持久化逻辑
  • 数据验证和规范化

要求: 编写独立测试文件或在现有测试中补充

4. 工具函数和辅助方法

  • 添加新的工具函数
  • 修改现有的数据处理逻辑

要求: 创建对应的 *.test.ts 文件

开发流程

1. 需求分析
   ↓
2. 编写/更新测试用例(描述预期行为)
   ↓
3. 运行测试(此时应该失败)
   ↓
4. 实现功能代码
   ↓
5. 运行测试直到全部通过
   ↓
6. 代码审查和提交

提交前检查清单

  • 运行 npm test 确保所有测试通过
  • 新增功能已添加对应测试用例
  • 修改的功能已更新相关测试
  • 测试覆盖了正常情况和边界情况
  • 没有跳过或注释掉失败的测试

测试命令

# 提交前必须运行
npm test

# 开发时推荐使用监听模式
npm run test:watch

# 查看测试覆盖率
npm run test:coverage

测试编写规范

1. 测试文件位置和命名

测试文件位置

所有单元测试文件统一放在 src/__tests__/ 目录下。

命名规则

  • 单元测试: <功能模块名>.test.ts<功能模块名>.spec.ts
  • 集成测试: <功能模块名>.integration.test.ts

目录结构示例

src/
├── __tests__/
│   ├── schema.test.ts           # 数据结构测试
│   ├── useStore.test.ts         # Store 状态管理测试
│   ├── layer-management.spec.ts # 图层管理功能测试
│   ├── utils.test.ts            # 工具函数测试
│   └── ...
├── components/
├── ts/
└── ...

命名示例

  • schema.tsschema.test.ts
  • useStore.tsuseStore.test.ts
  • 图层管理功能 → layer-management.spec.ts
  • 工具函数集合 → utils.test.ts

2. 测试用例结构

describe('功能模块名称', () => {
  beforeEach(() => {
    // 每个测试前的准备工作
  })

  it('应该做某件事(正常情况)', () => {
    // 准备数据
    const input = { /* ... */ }

    // 执行操作
    const result = someFunction(input)

    // 验证结果
    expect(result).toBe(expectedValue)
  })

  it('应该处理边界情况', () => {
    // 测试空值、极端值等
  })

  it('应该处理错误情况', () => {
    // 测试异常处理
  })
})

3. 测试描述规范

  • 使用中文描述,清晰表达测试意图
  • 格式: "应该 + 动词 + 预期结果"
  • 例如: "应该正确导入包含式神数据的文件"

4. Mock 使用原则

  • Mock 外部依赖Element Plus、LogicFlow 等)
  • 不要 Mock 被测试的核心逻辑
  • Mock 要尽可能简单和稳定

不需要测试的场景

以下情况可以不写单元测试:

  • 纯 UI 组件的样式调整
  • 简单的 getter/setter
  • 第三方库的直接调用
  • 临时的调试代码

但建议通过手动测试验证这些改动。

测试失败处理

如果测试失败:

  1. 不要跳过或删除测试 - 测试失败说明代码有问题
  2. 分析失败原因 - 是代码错误还是测试用例需要更新
  3. 修复代码或更新测试
  4. 确保所有测试通过后再提交

持续改进

  • 定期审查测试覆盖率
  • 补充缺失的测试用例
  • 重构重复的测试代码
  • 更新过时的测试用例