测试计划驱动开发模式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)，然后再进行开发。

由于开发者需要跟测试人员合作，开发者相对于测试人员更加了解项目需求，测试计划更多的依赖于开发者，而测试计划、开发承诺是受到审查的；所以也造不了假，对于团队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）

参考链接

TDD is dead. Long live testing.

Is TDD Dead?

TDD（测试驱动开发）是否已死？

TDD并不是看上去的那么美

心理学参考 之 承诺和一致原理

作者介绍

臧嘉玮 Vigor Zang，TPDD的发明者和布道者，主要研究方向为自动化系统和Web Development。曾就职于IBM Watson Commerce组，主要负责自动化测试和前端开发，任职期间受Watson Commerce Insight组的邀请，负责测试流程和测试基础设施的建设，包括测试框架、测试工具和性能检测和预警系统的架构、开发和维护。