谈谈测试驱动开发

2018-04-14 本文已影响40人郑经铧Monkey

背景

本人一直都从事 PHP 后端项目开发，一直使用 Laravel 框架。从业近 10 年来从未采用过测试开发，因为我一直都在外包公司工作，公司的性质决定「按期交付」为第一生命线，因此从未关注过 TDD 相关的信息，毕竟 TDD 在我看来耗费的时间过大，会影响项目进度。

不过由于公司老大的一再坚持，接下来三个月我要在公司内部主推测试，因此有必要花时间来整理一下学习路径。

测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码。也就是说在明确要开发某个功能后，首先思考如何对这个功能进行测试，并完成测试代码的编写，然后编写相关的代码满足这些测试用例。然后循环进行添加其他功能，直到完全部功能的开发。

我们这里把这个技术的应用领域从代码编写扩展到整个开发过程。应该对整个开发过程的各个阶段进行测试驱动，首先思考如何对这个阶段进行测试、验证、考核，并编写相关的测试文档，然后开始下一步工作，最后再验证相关的工作。下图是一个比较流行的测试模型：V测试模型。

【图 V测试模型】

在开发的各个阶段，包括需求分析、概要设计、详细设计、编码过程中都应该考虑相对应的测试工作，完成相关的测试用例的设计、测试方案、测试计划的编写。这里提到的开发阶段只是举例，根据实际的开发活动进行调整。相关的测试文档也不一定是非常详细复杂的文档，或者什么形式，但应该养成测试驱动的习惯。

测试驱动开发的基本过程如下：

TDD 对开发人员的素质要求非常高。新手看到TDD会欢欣鼓舞，因为他们「填坑」的工作就少了很多。但是他们没有能力来实践。
老手们在项目的压力下，早就麻木了，有时间写测试，还不如快速推进项目进度（比如我）。

所以，在团队内推动 TDD 需要公司内部有相应的资源才能比较好的推行，比如项目部给研发团队争取更宽松的时间，HR 给团队带来更专业的人：）

TDD不是银弹，不可能适合所有的场景，但这不应该成为我们拒绝它的理由。
也不要轻易否定TDD，如果要否定，起码要在认真实践过之后。

以上就是我当前对 TDD 的一些浅显的理解，接下来将在工作中更加细致的磨练相关技能。