文章目录1. 测试的是“行为”不是“实现细节”2. 单元测试要小、快、独立3. 测试命名清晰能表达意图4. 使用断言清晰表达期望5. 保持测试代码的可维护性6. 不要滥用 Mock / Stub7. 覆盖典型路径 边界 异常情况8. 遇 bug 要写“回归测试”9. 集成测试 单元测试结合使用10. 失败信息要清楚便于排查总结写好测试的黄金法则1. 测试的是“行为”不是“实现细节”✅ 测试应该验证功能是否正确而不是代码怎么写的。❌ 不要因为内部重构就需要改一堆测试。✅ 比如测试输出正确不关心你用的算法是循环还是递归。2. 单元测试要小、快、独立小每个测试验证一个明确的点。快运行速度快支持频繁运行。独立每个测试都可以独立运行互不依赖。3. 测试命名清晰能表达意图一个好测试名就像一句人话说明了功能点和预期TEST(ShoppingCartTest,AddingSingleItemIncreasesItemCountByOne)可读性 技巧。4. 使用断言清晰表达期望如EXPECT_EQ(price, 100)不要仅输出调试信息而要用断言验证否则不能自动发现错误。5. 保持测试代码的可维护性测试代码也是“产品代码”要注意不要重复明确 Setup抽象公共逻辑到TestFixture避免测试之间相互依赖6. 不要滥用 Mock / Stub使用 mock 要有理由不要“为 mock 而 mock”只 mock“你不控制的依赖项”比如数据库、网络、外部服务7. 覆盖典型路径 边界 异常情况确保你测试了类型示例正常情况add(2, 3)返回 5边界情况空输入、最大值、负数异常情况输入错误是否抛出异常特殊行为幂等性、重复操作是否一致8. 遇 bug 要写“回归测试”发现一个 bug → 先写测试重现它修复后 → 测试变绿避免以后再犯9. 集成测试 单元测试结合使用单元测试验证一个类/函数的行为集成测试验证模块之间协作是否正确端到端测试E2E模拟用户真实操作验证整个系统10. 失败信息要清楚便于排查不然你运行测试看到Expected: true, Actual: false这很难定位问题。可以这样写EXPECT_EQ(cart.getItemCount(), 1) Item count should be 1 after adding 1 item;总结写好测试的黄金法则法则说明独立每个测试可以单独运行快速跑得快能频繁运行可读测试名和内容能一眼看懂覆盖全面正常 异常 边界验证行为而非实现不跟着内部结构改及时更新和修复发现问题先补测试再修代码加入 CI/CD 流水线中保证代码提交/发布前都通过所有测试