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

你的团队真的在践行TDD吗？或许很多团队的答案是肯定的，对外也声明采用了测试驱动开发。但这种“声明”背后，往往隐藏着一个现实：很多团队在实际开发中，并无法真正满足TDD严苛的“先测试，后代码”循环。

尽管TDD理念先进——它通过预先编写测试来框定问题与边界，确保最终代码是可接受的——并且被许多公司所采纳，但它对开发者而言并不算友好，更像是一种理想化的开发范式。

为什么说TDD不够“友好”？

TDD的理念众所周知，但扪心自问，有多少开发者能在每次功能开发中都严格遵守其步骤？

从开发者的声音中，我们可以一窥端倪：

• 测试的目的被简化：测试有时只是为了验证“脑中的逻辑”变成了“自洽的代码”。
• 实践与理论的脱节：许多人在网上称赞TDD，却鲜少有人敢于承认它对自己无效。
• 理想与现实的冲突：没有截止日期的压力时，TDD很有趣，但“过度测试”确实存在。
• 能力与门槛：大多数程序员还不会或不擅长编写有效的测试用例。
• 知易行难：理念听起来简单，实践起来却困难重重。
• 流程的反人性：TDD有时被批评为“本末倒置”，让非生产代码（测试）统治了生产代码，在未充分理解问题前就试图构建高屋建瓴的解决方案，缺乏对开发实际和程序员的尊重。
• 优先级问题：在项目压力下，先写Case不如先写个小功能，边写边想、边写边改更符合现实节奏。
• 质量与效率的平衡：我们一切的最终目的是快速交付有价值、有质量的产品或服务，TDD只是手段之一，而非目的本身。
• 国内实践困境：以国内的敏捷实践环境，常常难以达到TDD的要求。

我相信，很多人难以做到纯粹的TDD。现今更常见的做法是 Unit Test，即在完成业务代码后再补充（单元）测试。从结果上看，Unit Testing和TDD都确保了功能通过测试，既然结果一致，为何要给自己“添麻烦”，非得提前写测试代码呢？

此外，开发者水平参差、测试技能不足，或是项目周期极其紧张，都让TDD的落地变得困难。许多开发者对TDD心存反感，至少潜意识的抵触是存在的。这种感受，就像小时候每天上学前，妈妈都会在耳边叮嘱每一步，虽然知道是为你好，但有时仍会感到不耐烦。程序员在面对繁琐的开发模式时，也可能选择“糊弄”——先写完业务代码交付功能，事后再补单元测试，以此将TDD要求搪塞过去。

TDD看似有效，但开发者普遍不愿严格执行，且极易“造假”（先写代码再补测试），管理层也难以有效监督开发过程是否真的遵循了TDD。因此，TDD是一种理想化的模式，仅适合特定气质的技术人员、团队和产品。

除了TDD，我们是否还有其他更务实的选择？

答案是肯定的。目前，一种名为 Test Plan Driven Development (TPDD)，即测试计划驱动开发的模式，正在一些团队中悄然应用。它也可被称为 Test Pre-Requisition Driven Development（测试前提驱动开发）。

TPDD究竟是什么？

与TDD要求“先写测试代码”不同，TPDD的核心是让开发者在编码之前，就参与到测试计划的制定中。具体来说，在接到需求后，开发者需要协助测试人员，基于需求共同构思并起草一份 测试计划 A，或称 开发承诺 (Development Promise)，之后再进入开发阶段。

由于开发者更懂需求，因此测试计划的制定很大程度上依赖他们的输入。这份开发承诺会接受审查（如来自技术组长），因此难以造假，对团队管理者而言，它是可监控、可追溯的。

哪些团队适合TPDD？

• 不喜欢或难以执行TDD的开发者及团队。
• 对外声称使用TDD但实际并未严格遵循的团队。
• 实施了TDD但代码质量未见明显提升的团队。
• 因TDD导致开发效率下降的团队。
• 开发者嫌TDD麻烦，但仍希望保障代码质量的团队。
• 开发者测试能力不足的团队。
• 项目截止日期非常紧张的团队。
• 初创或快速成长期的团队。
• 尚未引入TDD但正在考虑采用的团队。

详解“开发承诺”（测试计划A）

开发承诺类似于设计文档，但它更侧重于明确开发必须完成的事项，并指导测试人员的工作。它通常包含以下几个层级：

• Must Have – Critical Check Points (必须实现 – 关键检查点)
  • 对测试人员：需重点测试，并进行探索性测试。有条件的团队应加入自动化测试。
  • 对开发者：必须全部完成的功能点，否则视为工作未完成。
• Need Have – Important Check Points (需要实现 – 重要检查点)
  • 对测试人员：需重点测试的功能点。
  • 对开发者：必须完成绝大部分的功能，否则视为工作未完成。
• Should Have – Optional Check Points (应该实现 – 可选检查点)
  • 对测试人员：进行手动测试即可。
  • 对开发者：可选功能，根据实际情况决定是否实现。

“开发承诺”的核心作用

1. 明确任务优先级，为开发和测试提供清晰指南

   • 对开发者：是开发的“指导手册”，使其思路清晰，明确先做什么、后做什么。当开发者离职或请假时，其他成员也能据此快速接手。
   • 对测试人员：是测试的“指导手册”，使其明确哪些功能需要重点测试、哪些适合探索性测试、哪些应实现自动化并集成到CI/CD中。

2. 利用“承诺一致性”心理，潜移默化提升代码质量

   • 将测试计划A提交给测试人员和技术负责人后，便形成了一种“承诺”。根据心理学中的“承诺与一致”原理，人们会倾向于使自己的行为与承诺保持一致。这会使开发者在编码时更加谨慎，深知自己的代码至少要满足哪些测试条件，从而提升代码的可靠性和质量。

3. 赋能测试团队，提升整体效率

   • 测试人员可以基于测试计划A快速起草更详细的测试计划B（只需关注测试方法）。这大大减少了测试人员理解需求和准备测试用例的时间，使他们能将更多精力投入到探索性测试、自动化测试脚本开发或运维相关的工作中。

心理学参考：一旦我们做出了某种承诺或选择了某种立场，就会在个人和外部环境的压力下，迫使自己的言行与承诺保持一致，尽管有时这可能违背我们最初的意愿。

TDD 与 TPDD 的全面对比

TDD的优缺点

• 优点：理论上能提前明确接口、保障代码质量。
• 缺点：开发者抵触情绪高，执行度差，易“造假”（先写代码后补测试），测试代码本身质量可能不高。管理者难以有效监督实施过程，导致TDD的优势无法真正体现。

TPDD的优缺点

• 提高代码质量：通过先制定测试计划，使开发者对测试用例和环境有清晰认识，思路更条理；“承诺”的心理效应会潜移默化地驱动开发者写出更高质量的代码。
• 可监控、难造假：测试人员需依据开发者的承诺编写测试计划，管理者通过审查开发承诺即可直接监督TPDD的实施情况，基本杜绝了造假可能。
• 释放测试潜能：开发和测试前期已共同完成基础计划，测试人员得以节省大量需求理解时间，从而能更专注于探索性测试、自动化测试或运维工作。
• 向TDD平滑过渡：TPDD让开发者先行接触测试思维，团队在适应后可更好地向TDD过渡，此时TPDD可视为“测试前提驱动开发(Test pre-requisition Driven Development)”。
• 对开发者更友好：相比编写具体的测试代码，与测试人员共同构思测试用例和计划对多数开发者来说心理负担更小，更易执行。
• 对测试人员更友好：与开发者直接合作降低了测试准备难度，缩短了测试设计时间，并创造了提升其他技能的空间。
• 对管理者更友好：开发承诺和测试计划的实体化，使得管理者可以提前介入审查，而非仅仅依赖开发完成后的代码复审。

TPDD并非要完全取代TDD，而是为那些在TDD实践中遇到阻力的团队，提供了一个更渐进、更人性化、且同样能有效提升质量的替代路径。它强调沟通、计划与承诺，在理想与现实之间架起了一座务实的桥梁。如果你对这类开发模式的实践与探讨感兴趣，欢迎在云栈社区与其他开发者交流分享。