如何为CKEditor自定义插件添加单元测试及规范项目结构

一、项目结构优化建议 #

你当前的核心问题是业务代码与插件代码耦合，不符合CKEditor插件生态的标准规范，建议按以下思路调整：

• 将自定义subject插件拆分为独立的NPM包项目，完全剥离app.js、index.html等业务集成代码，后续通过本地软链接或者NPM安装的方式接入业务编辑器项目即可。
• 独立插件项目的标准结构参考：

ckeditor5-subject/
├── src/
│   ├── subject.js
│   ├── subjectcommand.js
│   ├── subjectediting.js
│   └── subjectui.js
├── tests/
│   ├── subject.test.js
│   ├── subjectcommand.test.js
│   └── _utils/ # 可选，存放测试通用辅助逻辑
├── package.json
└── README.md

• 如果不想拆分两个独立仓库，也可以采用monorepo结构，在现有项目下新建packages目录，分别存放业务集成代码和插件代码，兼顾本地调试效率和规范要求。

二、测试套件正确使用方式 #

@ckeditor/ckeditor5-dev-tests 本身支持外部自定义插件测试，你之前运行失败是两个配置问题导致：

1. 插件包未按CKEditor生态规范命名，独立插件的package.json中name字段需要符合ckeditor5-xxx的命名规则，比如你的插件可以命名为ckeditor5-subject
2. --files参数使用错误，该参数默认会自动匹配ckeditor5-[参数值]的包路径，正确执行测试的命令分为两种场景：
   • 按官方标准包结构开发时，执行命令：npx ckeditor5-dev-tests --files=subject
   • 自定义目录结构时，显式指定源码和测试文件路径，执行命令：npx ckeditor5-dev-tests --source-directories=./src --files=tests/**/*.test.js

• 如果觉得官方测试套件配置过重，也可以自行搭建Jest + jsdom的测试环境，模拟CKEditor编辑器上下文即可完成单元测试，更适合小型自定义插件的快速迭代。

三、TDD与CI/CD落地建议 #

• 单元测试优先覆盖核心逻辑：先测试command层的标签插入、删除、状态切换逻辑，再测试UI层的按钮状态、交互逻辑，最后做集成测试验证插件与编辑器其他功能（撤销、复制粘贴等）的兼容性
• CI流水线可以直接复用官方测试套件的命令，测试通过后自动发布插件包或者触发业务编辑器的构建流程

内容的提问来源于stack exchange，提问作者staplegun