后端测试
面向 BFF 和后端服务的测试入口，组织领域规则、边界、契约、数据库集成和系统验证的分层实践。
#type / howto
#status / growing
#tech / dev / test
[!info] related notes
- 所属 MOC: Testing MOC, 后端开发 MOC
- 相关主题: Monorepo 测试架构, 契约测试与 CDC, 测试数据库的方案
- 相关实践: nodejs后端api测试搭建集成测试框架, 事件总线下多模块业务原子性问题
- 相关工具: postman-scripts-tests-and-runner, postman-cli-and-monitors
后端测试
目标
后端测试的重点不是“接口能手点通”这么简单，而是把不同风险拆到合适层级去验证：
- 领域规则
- handler / service 边界
- 数据库集成
- contract tests
- 少量跨服务工作流
步骤
1. 先把核心规则放到快速测试层
最值得优先测的是：
- 权限判断
- 状态流转
- 数据校验
- 计费/规则计算
- 幂等和补偿逻辑
这些地方最适合 TDD 或至少自测试代码保护。
2. BFF 重点看边界转换
BFF 往往不是算法核心，而是：
- request validation
- auth / permission
- orchestration
- downstream service coordination
这层的 contract tests 往往比大量纯单测更值钱。
3. 服务层补真实集成
不要把数据库、消息队列、outbox、事件发布全都 mock 掉，否则你只能验证“代码像是会工作”，而不是“系统真的能工作”。
这一层通常要补：
- DB integration
- event publish / consume
- sandbox integration
- migration compatibility
验证
一个更健康的后端测试结构通常是：
- 大量领域与应用层快速测试
- 少量 DB / contract / integration tests
- 极少量跨服务工作流验证
常见问题
只靠 Swagger 手点
这适合开发早期快速自测，但不能替代回归保护和集成验证。
过度依赖 mock
如果关键边界都被 mock 掉，很多真实协作问题要到联调或上线才暴露。
没有 contract 层
单测很绿但边界协议已经碎了，是服务化架构里非常常见的事故来源。
最短记忆方式
后端测试要分层：规则在快测试里锁住，边界靠契约和集成硬化，系统流程只留少量高价值验证。