单元测试、集成测试与端到端测试：该怎么选？
Unit Testing, Integration Testing, and End-to-End Testing: How to Choose?
开发中常见的问题是：“这个功能测过了吗？”但“测过”并不只有一种方式。
A common question in development is: “Has this feature been tested?” But testing comes in more than one form.
单元测试、集成测试和端到端测试分别解决不同层面的问题。
Unit testing, integration testing, and end-to-end testing solve problems at different levels.
单元测试：验证业务逻辑
Unit Testing: Verify Business Logic
单元测试只关注一个类、一个方法或一段独立逻辑。数据库、MQTT、HTTP 等外部依赖通常用 mock 模拟。
Unit tests focus on one class, one method, or one isolated piece of logic. External dependencies such as databases, MQTT, and HTTP are usually mocked.
例如门禁人员下发：收到 addUserRet 后状态是否变为 success；旧命令的 Ret 是否不会覆盖新状态。
For example, in access-control user provisioning: does addUserRet change the status to success? Can an old Ret avoid overwriting a newer command state?
优点是快、稳定、定位问题准确。
The benefits are speed, stability, and precise failure diagnosis.
但它不能证明真实数据库事务或 MQTT 消息是否真的协作正常。
However, it cannot prove that real database transactions or MQTT messaging work correctly together.
集成测试：验证组件协作
Integration Testing: Verify Component Collaboration
集成测试验证多个真实组件是否正确配合，例如 Controller、Service、MySQL、Redis、MQTT。
Integration tests verify that real components work together correctly, such as Controllers, Services, MySQL, Redis, and MQTT.
例如小程序下单：调用下单接口后，订单是否写入数据库、场地是否被占用、事务是否正确提交。
For example, for mini-program ordering: after calling the order API, is the order written to the database, is the venue reserved, and is the transaction committed correctly?
又例如门禁人员下发：一台实例提交 last_msg_id 后，另一台实例收到 Ret 是否能查到记录并更新状态。
Another example is access-control provisioning: after one instance commits last_msg_id, can another instance receiving the Ret find the record and update its status?
集成测试能发现 SQL、事务、配置、序列化和异步协作问题。
Integration tests can reveal SQL, transaction, configuration, serialization, and asynchronous collaboration issues.
端到端测试：验证用户完整流程
End-to-End Testing: Verify Complete User Journeys
端到端测试从用户视角验证完整操作流程，通常通过网页或小程序 UI 完成。
End-to-end tests verify complete workflows from the user’s perspective, usually through web or mini-program UI.
例如小程序下单：选择场地、提交订单、支付成功，并看到“预约成功”。
For example, in mini-program ordering: select a venue, submit an order, complete payment, and see “Booking confirmed.”
它验证的是“用户能不能真正完成操作”，而不只是某个接口是否正确。
It verifies whether users can actually complete an operation, not merely whether one API works.
端到端测试最接近真实使用，但运行最慢，失败后也更难定位原因。
End-to-end tests are closest to real usage, but they are the slowest and usually the hardest to debug when they fail.
如何配合使用？
How Should They Work Together?
| 场景 / Scenario | 优先测试 / Preferred Test |
|---|---|
| 状态转换、参数校验、金额计算 / State transitions, validation, price calculation | 单元测试 / Unit testing |
| Controller、真实 SQL、事务、Redis、MQTT / Controllers, real SQL, transactions, Redis, MQTT | 集成测试 / Integration testing |
| 小程序下单、取消订单、支付后查看订单 / Mini-program ordering, cancellation, post-payment order view | 端到端测试 / End-to-end testing |
| 真实门禁、灯控、网络质量、固件协议 / Real devices, lighting control, network quality, firmware protocols | 联调或端到端测试 / Device integration or E2E testing |
推荐策略：
Recommended strategy:
- 用大量单元测试覆盖业务规则。
Use many unit tests to cover business rules. - 用少量集成测试覆盖数据库、事务、消息等关键技术边界。
Use fewer integration tests for critical technical boundaries such as databases, transactions, and messaging. - 用更少的端到端测试覆盖最重要的用户流程，例如下单、支付和取消订单。
Use even fewer end-to-end tests for the most important user journeys, such as ordering, payment, and cancellation.
单元测试验证代码逻辑；集成测试验证组件协作；端到端测试验证用户流程。
Unit tests verify code logic; integration tests verify component collaboration; end-to-end tests verify user journeys.
