测试策略

测试在 FastQTools 中不是收尾动作，而是维护边界的一部分。一个修改只有在对应层级的测试里被表达清楚，才算真正可审阅、可回归、可长期维护。

分层验证思路

层级	关注点	典型位置
单元测试	小范围逻辑、边界条件、错误路径	`tests/unit/`
集成测试	模块协作、配置与 I/O 组合	`tests/integration/`
端到端测试	CLI 行为、帮助输出、真实工作流	`tests/e2e/`
文档测试	站点 IA、页面骨架、内容契约	`docs/tests/`

维护者的基本节奏

为新行为或修复先写失败的测试；
只实现让测试变绿所需的最小改动；
针对改动范围运行最小相关测试；
再回到更高层的回归验证，例如 ./scripts/core/test 或文档构建。

常用命令

bash

./scripts/core/test
./scripts/core/test --unit
./scripts/core/test --integration
./scripts/core/test --e2e

如果你修改的是文档站，请在 docs/ 目录执行对应的 Node 测试与构建；如果你修改的是 C++ 代码，请同时关注 clang-format、clang-tidy 与相关测试目标。

判断测试是否足够的简单标准

它是否精确表达了这次改动真正承诺的行为？
它失败时，是否能清楚说明为什么失败？
它通过时，是否真的证明了修改目标，而不是只是覆盖到某段代码？

测试不是为了制造更多文件，而是为了让维护者能在未来更有把握地修改同一块实现。