测试计划驱动开发模式 TPDD：一种比 TDD 更友好的开发模式

相信大部分开发团队都在使用TDD，而且还有不少开发团队都 对外声明 在使用 TDD 开发模式。

之因此说是“对外声明”，是由于不少开发团队虽然号称使用的是 TDD 开发模式，实际开发过程当中却没法知足 TDD 的要求。

实际上，测试驱动的开发模式确实有效，它将可能发生的问题用测试代码预先解决，只有经过测试代码后的代码才是能够接受。当前有不少公司都在应用 TDD，但 TDD 并非一个开发者友好的开发模式，只是一个理想化的开发模式。

为何 TDD 不是一个开发者友好的开发方式？

你们都知道 TDD 是什么，但是试问全部的开发者能保证每次开发过程当中会知足 TDD 的要求吗？

听听你们的声音：

• 测试也只是保证脑内想法转成代码的时候，逻辑自洽

• Lots of people on the internet talk about how good TDD is, but people were afraid to say it wasn’t working for them.

• 没有 deadline 的威胁，我很喜欢 TDD，可是过分测试是存在

• 大多数程序员还不会写测试用例

• 看起来容易，可是作起来难

• Yes. TDD 该死。TDD 死了，T 才能正常T，程序员作正常人，团队作正常团队。TDD死，不是由于程序员达不到它的要求，是它没打算尊重程序员，尊重开发实际。TDD 本末倒置的价值观，非生产代码统治生产代码，没理解问题就想对问题高屋建瓴，TDD 是码农界的纳粹，流程方法论原教旨主义。

• TDD 是否已死先不说，不少程序员连写出基本的整洁代码都作不到，还能期望他先写测试吗

• 新手看到 TDD 会欢欣鼓舞，可是他们没有能力来实践。老手们在项目的压力下，早就麻木了，先写 case 还不如写好代码再补 case 呢，不少东西我还没时间想清楚，怎么写 case？不如先写个小功能先，边写边改

• 其实咱们全部一切的目的是为了快速的交付有价值，有质量的产品或者服务，赢得公司的生存和发展空间。为了达到这个目的，咱们有不少种的手段。但手段不是目的。

• 以国内的敏捷实践来说，彻底达不到 TDD 的要求

• TDD 力量和问题都源自 test first。要能 test first，写代码以前要想得更清楚；代码得要有良好的可测试性 致使其写的代码是为了知足测试的，而忽略了代码质量和实际需求

• 不过，我还真是见过使用 TDD 开发的不错的项目，只不过那个项目比较简单了。更多的状况下，我看到的是教条式的生硬的 TDD，因此，不奇怪地听到了程序员们的抱怨——“自从用了 TDD，工做量更大了”。固然，这也不能怪他们，TDD 原本就是很难把控的方法。

• 等等等等 来自于网络

我相信不少人都作不到，如今更多的开发者作的更多的是 Unit Test，就是写业务代码完了以后再写（单元）测试，而这个 Unit Testing 单元测试与 TDD 测试驱动开发 的结果一致，即二者都保证了功能经过了测试，二者结果同样为何还给本身添麻烦，提早写测试代码呢？

还有些开发者因为水平不足；或是不会测试；有些项目很是紧急根本没时间作测试。

不少开发者都很反感 TDD，至少是在潜意识中很反感（除了自身天天用不着 TDD 那些人）; 试想你在小时候，天天上学前妈妈都会在耳边絮叨都要你当心，而后告诉你每一步的步骤，每一步都要正确，有时候真的很烦，因而咱们左耳朵进右耳朵出，就会不耐烦的说“好了，好了，我知道了”；程序员也是同样的，对于很繁琐的一些开发模式他们会糊弄过去，方法之一就是先写完业务代码，完成业务再说测试，写完后再写单元测试，把 TDD 给搪塞过去。

但是你知道你妈妈对你是好的，并且她在养你，因此就没说什么；程序员和公司的关系与之很类似，公司也在养你，它但愿你写的代码是好的，是可靠的，因此它要求你用 TDD 的方式编写代码。

TDD 看似有效，可是开发者的广泛不肯意作，而且很容易造假（不少人都是先写完代码，再写测试代码），并且没法监督开发者是否采用 TDD 这种开发模式，也就是说 TDD 是理想化的开发模式，若是要执行起来是最好不过的，可是真正严格执行的团队又有多少呢？肯定全部的开发人员都严格执行吗？

由此得知，TDD 是很是理想化的开发模式，只有特定的程序员、团队、产品和公司才适合这种理想化的开发模式

除了 TDD，咱们还有哪些替代方案？

有，目前有种开发模式正在被一些公司的部门使用，就是 Test Plan Driven Development，即测试计划驱动开发模式，或是 Test Pre-Requisition Driven Development，即测试前提驱动开发。

TPDD 究竟是什么？

相比每次开发以前先写测试代码，咱们可让开发人员参与编写测试计划，也就是说，在收到项目需求时，开发者须要帮助测试人员根据项目需求思考测试计划，并起草 测试计划 A (或者叫作开发承诺 -Development Promise)，而后再进行开发。

若是对软件测试、接口测试、自动化测试、性能测试、LR脚本开发、面试经验交流。感兴趣能够175317069，群内会有不按期的发放免费的资料连接，这些资料都是从各个技术网站搜集、整理出来的，若是你有好的学习资料能够私聊发我，我会注明出处以后分享给你们。

因为开发者须要跟测试人员合做，开发者相对于测试人员更加了解项目需求，测试计划更多的依赖于开发者，而测试计划、开发承诺是受到审查的；因此也造不了假，对于团队 lead 负责人而言是可监控、可调查的。

适用对象

• 不喜欢怎么 TDD 开发模式的开发者，和相关的团队和企业
• 没有严格要求按照 TDD，然而对外声称使用 TDD 开发模式的开发者，和相关团队和企业
• 执行了 TDD 这种开发模式，然而质量没有明显的提升的团队和企业
• 使用 TDD 致使开发效率下降的团队和企业
• 开发者不喜欢 TDD 这种开发模式，嫌麻烦，可是还想要保证代码质量的团队或企业
• 开发者没有足够的能力进行 TDD 的团队和企业
• 产品的截止日期很紧张的企业
• 初创团队和企业
• 正在上升期的团队和企业
• 尚未应用 TDD 这种开发模式，可是准备使用 TDD 的团队或企业

什么是开发承诺和测试计划 A

开发承诺相似于 design doc，不过其中讲述了开发者必须完成的功能，须要作的功能以及可选作的功能，而且还提供了测试人员须要作的事情。

开发承诺 — 测试计划 A 以下所示：

• Must Have – Critical Check Points
• 必需要所有完成的功能点，不完成工做没有完成
• 测试人员重点测试的功能点，而且 adhoc test，有能力的团队须要加入自动化测试
• Need Have – Important Check Points
• 重要的功能点，必需要完成绝大部分的功能，没有完成绝大部分，工做没有完成
• 测试人员重点测试的功能点
• Should Have – Optional Check Points
• 可选的功能，开发者可选
• 测试人员手动测试

开发承诺和测试计划 A 有什么做用？

• 开发承诺 测试计划 A 的第一个做用是，开发者 (测试者) 对于任务的优先级有很清晰的认识

• 为了给开发者本身看的（或是其余开发者，假如开发者离职或是请假，其余开发者就能够看测试计划迅速开发），做为开发时的指导手册，这样开发者的头绪就更加清晰，也知道任务的优先级 ---- 先作什么，后作什么。

• 为了给测试人员看的，做为测试的指导手册，这样测试人员就知道什么功能须要重点测试、什么东西须要进行实验性的测试，以及什么功能须要实现测试自动化以便于加入到 CI 和 CD 之中。

• 开发承诺 测试计划 A 的第二个做用是，承诺使开发者的开发过程更加当心

• 将测试计划 A 交给测试人员和开发组长，利用心理学中“承诺”做用，使本身的言行和承诺一致。这样的话，开发人员就知道本身的 code 至少要知足什么条件，至少要过什么样的测试，因此开发时会更加当心，代码的质量和可靠性也会获得很高的提高。 开发承诺 测试计划 A 的第三个做用是，促进测试人员的工做进度，使测试人员有更多的时间进行自动化、adhoc 测试或是运维方面的工做

• 测试人员会根据测试计划 A 起草测试计划 B，只须要在测试计划 B 中添加如何进行测试便可。

参考：一旦咱们作出了某种承诺，或是选择了某种立场，就会在我的和外部环境的压力下，迫使本身的言行与承诺保持一致，尽管这种行为有悖于本身的意愿。

TDD 和 TPDD 有什么区别？

TDD 的优缺点

TDD 是先写测试代码，判断业务代码是否能够经过测试代码。看似有效，可是开发者的广泛不肯意作，或是完成度不好，或是作了以后致使没有按时完成任务；而且很容易造假，不少人都是先写完代码，再写测试代码；或者测试代码质量不高；或是测试用例很差。

对于管理者而言，他们没法监督开发者是否有效的沿用 TDD 这种开发模式，彻底体现不了 TDD 的优点。

TPDD 的优缺点

1.提升代码质量

• TPDD 是先写开发承诺，使开发者对测试用例和测试环境有清晰的认识，思惟会更加清晰有条理；而且因为承诺的心理做用，开发者会潜移默化的提升代码质量。

2.可监控和不可造假

• 由于测试人员须要根据开发者的开发承诺编写测试计划，可使管理者很直接的监督开发者是否采用 TPDD 这种开发模式（经过审查开发承诺），因此不可能造假。

3.有时间进行其余方面的提高，例如自动化、运维等

• 因为开发者和测试者已经将基本的开发承诺—测试计划 B 写出来了，对于测试者来讲将会用更少的时间作功能的理解和测试的准备，这将给测试人员更多的时间进行 adhoc 测试、自动化测试或是运维功能的开发和维护。

4.更好的接受 TDD

• 因为开发者已经接触了测试，使用 TPDD 后的团队会更好的接受 TDD，这时 TPDD 又能够被称为 Test pre-requisition Driven Development。

5.对开发者友好

• 相对于每次开发以前写测试代码，只须要与测试人员想出测试用例，对于开发者来讲这是更加容易的

6.对测试人员友好

• 由于与开发者的直接合做，测试的准备的难度大大的下降，测试计划和测试用例的思考时间缩短，而且有时间空余去作一些自动化或是运维方面的工做。

7.对管理人员友好

• 因为开发承诺和测试计划的实体化，管理人员就能够提早进行审查，而不是等待开发结束后进行代码审查（code review）