共计 1809 个字符，预计需要花费 5 分钟才能阅读完成。
| 导读 | 试驱动开发可以在很多环节里体现，同样，我们也可以主观地把 TDD 的思维运用到各个环节当中去。 |
相信对敏捷熟悉的朋友对测试驱动开发（TDD）的概念都不会陌生。测试驱动开发强调通过预定义的测试标准驱动开发写出符合标准的代码。不过现在越来越多人会把 TDD 等同于单元测试驱动开发，即 UTDD。我并不否认 UTDD 的价值，不过我更想强调应该把 TDD 当作一种思维。TDD 的思维其实非常合理，做任何事情都应该有一个预期的目标和标准，如果目标和标准不清晰，就很难确保产出的价值。
“The original description of TDD was in an ancient book about programming. It said you take the input tape, manually type in the output tape you expect, then program until the actual output tape matches the expected output. After I’d written the first xUnit framework in Smalltalk I remembered reading this and tried it out. That was the origin of TDD for me. When describing TDD to older programmers, I often hear,“Of course. How else could you program?”Therefore I refer to my role as‘rediscovering’TDD.”
—Kent Beck, re-discoverer and namer of Test-Driven Development
从 Kent Beck 的表述来看，TDD 最初也更像是一种思维，并且应该是理所当然的做事方式。
回到研发工作当中，测试驱动开发可以在很多环节里体现，同样，我们也可以主观地把 TDD 的思维运用到各个环节当中去。例如：
契约测试是期望消费者和提供者之间基于预先定义的契约进行协作的实践。所以我们可以认为契约测试符合测试驱动开发的思维，这样的协作过程规范了写作标准，避免了传统的口头或文档承诺带来的交付结果与预期不匹配的问题。
在敏捷团队中教练会经常强调验收标准的重要性，而实际上验收标准对任何一个团队都不可忽略。验收标准在需求梳理过程中，迭代计划阶段都成为团队参考的重要依据。而在 Thoughtworks 推行的实践中，“开卡”也是把验收标准的价值进一步延伸的实践。
“开卡”的做法是在具体的开发人员准备开发某一个用户故事之前，需要基于自己对需求的理解并结合验收标准向产品、测试以及相关人员讲述对需求的理解。通过这种方式对齐需求验收标准，降低功能开发产生偏差的风险，同时也是质量内建的有力措施。当然，除了开卡之外，还有行为驱动开发（BDD）等实践都是把验收标准与研发过程有效结合的实践。而类似的实践都符合测试驱动开发的思维。
通过以上的实践我们能理解测试驱动开发的思维，会强调先有参考标准，再基于标准去实现交付。自然我们也可以把这种思维进一步扩展到更多的层面，比如通过预定义的标准驱动团队的行为。而在现实情况下却也并不容易。
不管哪种场景下，遇到的第一个问题就是如何制定标准、如何确保达成共识的标准、标准如何保持更新。
很多团队对标准的第一印象往往是固化了大家的行为，对团队要求又提高了，推广时阻碍太多等等。而基于这些担心和固有印象一直守着原有的工作模式不想改变。
第二个关键点则是如何驱动。标准驱动在有了标准之后面对的就是如何产生驱动力的问题。我也见过太多的团队标准都是有的，却发现总是不能按照标准执行。有人说标准不适合自己，有人说标准太多影响现有工作，也有人说标准增加了工作复杂性。所以，往往在标准没有执行之前就被否定了。而让团队愿意依据标准执行无非从两个角度入手：
第一是标准要与团队甚至个人痛点相结合；
第二是标注的产出要获得团队的共识和认可。
回到本文主题上，测试驱动开发的运用是在理解测试驱动开发思维的前提下，找到适合的场景运用适合的实践的过程。从我们比较熟知的 UTDD 到 ATDD，再到 BDD 以及本文延伸出的很多观点，都不是对所有团队通用的。与敏捷本身类似，思维永远是实践的基础！
