课程背景

背景理解

工行创新中心，外包人员作为编码主力，普遍拥有1-3年开发经验，在 DevOps大趋势下，能够做到持续部署，但受发布窗口制约，两周投产一次。开发人员先编码后补测试，已经能够达到比较高的测试覆盖率要求。

希望通过引入 TDD，进入提升代码质量和开发效率，减少不必要的返工。

存量代码在编写时没有考虑可测试性，没有合理抽象和分离关注点，导致后期添加单元测试的成本较高。

在已经手工测试过证明没有问题的代码上添加单元测试，也让人有画蛇添足的感觉。

并且按照以前的习惯，在需求变更或修复 Bug 后会进行手动测试，现在还要修改单元测试代码，更会造成一种「单元测试维护成本很高」的误解。

如果能保证新增的代码都有测试覆盖，整体测试覆盖率就会持续上升。

利用 TDD（测试驱动开发）的方式，在开发新功能，修复 Bug，做需求变更前，先新增或修改测试代码，再修改实现代码，测试运行通过即代表工作完成，减少了大量的手工测试和 Debug 时间，在完善的测试覆盖下还可以进行大胆重构，这样将极大提高开发效率和代码质量。

本次培训将与大家介绍一种不同的开发方式「测试驱动开发」，对比这种开发方式和以前开发方式的不同，以及在组织中应用 TDD的策略和经验。

实施 TDD能影响哪些指标？

有效实施 TDD的团队，能明显提升「测试覆盖率」，降低「缺陷率」，缩短「周期时间（LeadTime）」，增加迭代待办中的「业务需求占比」。

如何在组织中推广 TDD？

做好 TDD和推广 TDD 是两回事。培训是推广 TDD策略中的一环，能帮助开发人员做好 TDD。

推广 TDD 的真正困难并不在 TDD本身，而在于开发模式的转型，需要在「个人」，「团队」，「公司」三个层面解决「愿不愿意做」和「能不能做好」两个方面的问题。

问题解答：

1、如何确保都实施了TDD？

先解决人的问题。把责任落到每个小组的技术 Leader头上，给与支持。如果他都不愿意做，再怎么检查也没用。只要他认可了，会做了，团队就没问题。

技术上用「小步提交」+「质量门禁」是对的，门禁有问题就解决门禁的问题，存量测试运行慢就要重构存量测试，减少集成测试数量，逻辑下沉到单元测试来验证。

2、TDD度量标准有待确认？

培训前对「测试覆盖率」，「缺陷率」，「周期时间」，「迭代业务需求占比」收集基线数据。

培训后对知识点进行考试，定期对代码进行抽查，每个迭代对上述指标进行统计，关注趋势。

3、部门内如何推广，有待确认：

参见上面「如何在组织中推广 TDD？」。

案例评审时机及测试参与度方面：是否必须有测试案例评审，如果没有如何确认实施了TDD。

在第二天下午的「TDD 完整开发流程」模块解答。

4、TDD实施标准有待确认：

在第二天下午的「TDD常见问题答疑」模块进行解答。

课程对象

●  架构师

●  Tech Lead

●  前后端程序员

课程时长 

3天（6 小时/天）

课程形式 

本课程为工作坊形式，形式包含：

●  生动的讲解

●  现场编码演示

●  结对的编码练习

●  基于代码的深度讨论

课程收益 

完成本次培训后，学员能够理解：

●  TDD 和原有开发方式的对比

●  Mock/Stub 技巧

●  关注点分离技巧

●  利用数据驱动测试降低测试维护成本

●  如何测试私有方法

●  利用面向对象设计提升可测试性

●  TDD 的三条规则

●  掌握 TDD 的四步

●  30+ TDD 练习的题目

●  在特定的技术栈上进行 TDD 开发

●  分层自动化测试理论

●  测试景深理论

●  高效使用 IntelliJ IDEA 的技巧

课程大纲