单元测试落地

题记

从业六年有余，从后台到移动端，从开发到项目负责人，凡事皆抱着学习的心态在做。一路走来，不敢说有什么成绩，但也尽职尽责，一步一个脚印走的踏实。“逝者如斯夫”，倘若能将人生的这笔流水账记录下来，也不失为一件幸事。又所谓”不积小流无以成江河“，那就从今天起，点滴积累吧！

背景

2017年9月初，在收尾了H项目后，被领导安排到Z项目救火。当时，客户对已经进行了两个月的单元测试工作所取得的进展极为不满。负责这项工作的同事，忙的也是焦头烂额，苦不堪言：

• 项目模块多，且从开始就未采用单元测试
• 项目采用插件化开发，有技术瓶颈需要攻关
• 开发兄弟主要精力放在了技术上，忽略了业务
• 多次无法实现预定目标后，客户失去了耐心
• 彼此的不信任在持续累积

解决方案

在深入了解现状、明确我们现有能力结构以后，我制定了如下解决方案，并跟客户进行了坦诚的沟通，获得了客户对方案的理解和认可：

• 降低技术预研工作的优先级， 明确在现有能力结构下，我们能做什么，不能¹做什么
• 选典型、高价值业务场景，梳理清楚业务流程、测试思路和实现逻辑
• 对这些业务场景进行单元测试覆盖，并制作成案例
• 记录总结经验教训，形成指导手册
• 对所有开发兄弟进行分享
• 在后续迭代中，将单元测试作为基本要求，纳入版本实施计划²，可以是对新业务，也可以是对原业务的补充

里程碑

• 2017年9月12日，实施计划评审通过
• 2017年9月25日，方案评审通过
• 2017年10月18日，案例和指导手册评审通过
• 2017年10月23日，对所有开发兄弟进行了分享

注

---

1. 其实能和不能都不是绝对的，要综合考虑实现的复杂度、所花费的代价等因素，就这里的“不能”部分，其实可以通过UI的自动化测试很方便的实现。 ↩︎

2. 后续还有至少三点工作要继续跟踪：接入持续集成、code review、计入绩效。 ↩︎