认知改变

• 客观、全面的角度认识单元测试价值与误区

单测价值

• 提升代码质量：早发现、早修复问题

• 简化调试：快速定位错误

• 充当文档：示例化代码使用方法

• 支持重构：自信地改进代码，不破坏功能

• 促进设计：反向驱动优化代码结构和设计

• 快速反馈：立即知道改动效果

• 减少集成问题：单元测试通过减少集成时的错误

• 提高团队信心：确信新改动不会引入问题

• 节省成本：长期来看减少修复工作和成本

• 增强适应性和可维护性：使代码易于更新和维护

常见误区

误区 0：频繁变更的代码不适用单元测试

• 单测价值不会因变更频率而下降

• 重点测试那些最关键和最有可能出错的部分

• 优化代码设计，通过抽象、封装，将稳定和变化部分分开，针对稳定部分测试

误区 1：单元测试浪费时间

• 单元测试虽代码多但不耗时，因结构简单，不同单测用例可快速复制及小改实现

• 各种大模型代码生成工具大大简化了重复性的工作

误区 2：写单元测试太难

• 反向审视代码的可测试性

• 单元测试框架基本用法掌握

• 从简单的单元测试开始

误区 3：代码太简单，不需要测试

• 即使是简单的代码也可能包含隐藏的缺陷

• 代码会持续迭代，单元测试有助于未来代码的重构和维护

误区 4：单元测试无法覆盖所有问题

• 客观事实，并且任何测试都不能保证覆盖所有问题

• 但它是质量保证的重要组成部分，与其他类型的测试（如集成测试、系统测试）一起形成多层防护，最大程度降低出现问题的概率

误区 5：现有代码太难添加单元测试

• 逐步重构策略

• 添加新功能或修复缺陷时引入单元测试

误区 6： 单元测试一味追求覆盖率

• 100%是终极目标，也可能实现，但仍要看投入产出比

• 项目对代码质量要求比较高，可以适当提高单元测试覆盖率的要求

• 区分核心非核心流程以及代码，优先覆盖核心流程代码

误区 7：测试应该由专门的测试团队完成

• 测试从业务场景入手

• 研发从代码入手，且更早、代价更小

误区 8：使用单测框架的各种高级特性才能体现能力或覆盖测试场景

• 单元测试技术要求并不高，大多数框架已足够

• 团队应统一单元测试框架

• 代码难以测试通常意味着需要改进代码的可测试性

• 优先考虑重构代码，而非寻找更复杂的测试框架

误区 9：必须详细了解代码实现逻辑才去写单测

• 无需关心实现，而是关心是否按预期提供了能力

• 实现内部若依赖了外部类，通过 mock 来解决