相信熟悉敏捷的朋友对测试驱动开发（TDD）的概念不会陌生。测试驱动开发强调通过预定义的测试标准驱动开发来编写符合标准的代码。但是现在越来越多的人会将TDD等同于单元测试驱动开发，即UTDD。我不否认UTDD的价值，但我想强调的是，TDD应该算是一种思维。TDD的思路其实是很合理的。做任何事情都应该有一个预期的目标和标准。如果目标和标准不明确，就很难保证产出的价值。“TDD的最初描述是在一本关于编程的古老书籍中。它说你拿走输入磁带，手动输入你期望的输出磁带，然后编程直到实际输出磁带与预期输出相匹配。在我用Smalltalk编写了第一个xUnit框架之后，我记得读过这篇文章并尝试了一下。这就是我TDD的起源。在向年长的程序员描述TDD时，我经常听到，“当然。你还能怎么编程？”因此，我将自己的角色称为“重新发现”TDD。”——KentBeck，测试驱动开发的重新发现者和命名者从KentBeck的说法来看，TDD起初更像是一种思考，它应该是一种自然的方式回到研发工作，测试驱动开发可以体现在很多环节，同样的，我们也可以主观地将TDD思想应用到各个环节，例如：契约测试契约测试就是期望之间协作的实践基于预定义合同的消费者和提供者。因此，我们可以认为契约测试符合测试驱动开发的思想。这样的协作过程规范了写作标准，避免了传统口头或文件承诺带来的交付结果与预期不匹配的问题。需求验收标准在敏捷团队中，教练经常强调验收标准的重要性，但实际上验收标准是任何团队都不能忽视的。验收标准已经成为团队在需求梳理和迭代规划过程中参考的重要依据。在Thoughtworks推动的实践中，“开卡”也是一种进一步延伸验收标准价值的实践。“开卡”的方法是具体的开发人员在准备开发某个用户故事之前，需要根据自己对需求的理解，结合自己对需求的理解，向产品、测试和相关人员说明自己对需求的理解与验收标准。以这种方式调整需求验收标准可降低功能开发中出现偏差的风险，同时也是衡量内置质量的有力措施。当然，除了开卡，行为驱动开发（BDD）等实践也是将验收标准与研发流程有效结合的实践。类似的做法很符合测试驱动开发的思想。标准驱动通过上面的实践，我们可以理解测试驱动开发的思想，会强调先有参考标准，再根据标准进行交付。自然，我们也可以将这种思考进一步扩展到更多的层面，比如通过预定义的标准来驱动团队的行为。但实际上并不容易。不管是什么场景，首先遇到的问题就是如何制定标准，如何保证标准的共识，以及如何保持标准的更新。很多团队对标准的第一印象是固化了大家的行为，提高了对团队的要求，晋升障碍太多等，基于这些顾虑和固有印象，我一直坚持原来的工作模式并且不想改变它。第二个关键点是如何开车。标准驱动的问题是有了标准之后如何产生驱动力。我也看到有太多的团队标准存在，但我发现他们不能总是按照标准执行。有人说标准不适合自己，有人说标准太多影响现有的工作，还有人说标准增加了工作的复杂性。因此，标准往往在实施之前就被否决了。要让团队愿意按照标准执行，无非要从两个角度入手：第一，标准要结合团队乃至个人的痛点；二是标记输出要得到团队的共识和认可。回到本文的主题，测试驱动开发的应用，就是在理解测试驱动开发思想的前提下，找到合适的场景，使用合适的实践的过程。从大家熟知的UTDD到ATDD，再到BDD以及本文延伸的诸多观点，并不是所有团队都通用的。与敏捷本身类似，思考永远是实践的基础！
