本文翻译自Dan North的文章"Introducing BDD"。 我遇到了一个问题。当我在不同环境的多个项目中使用和教授类似测试驱动开发(test-driven development, TDD)这样的敏捷实践时，我总是能遇到来自程序员们相同的困惑和误解。他们想知道从哪里开始、测什么不测什么、一次测试多少、谁来调用他们的测试以及如何理解为什么一个测试失败了。 越是深入TDD，我越能感觉到我对TDD认知过程是时断时续、逐步掌握的，还远未进入到死胡同。我记得多数时间我想到的都是"这只是别人告诉我这样做的"，而不是"哇，我明白为何要这样做了"。我断定一定可以通过某种方法将TDD直截了当地呈现给那些优秀的程序员们，并且可以避免所有陷阱。 ...
本周一已经投奔ThoughtWorks的Dreamhead因公事回到沈阳，来到我们公司看望以前的同事。他谈到业界的一种说法：ThoughtWorks在"怎么做"上达到了很高的高度，但是在"做什么"上与Google这样的公司相比还有差距。既然ThoughtWorks在"怎么做"方面树立了榜样，那么这个公司推出的产品估计在"怎么做"上对其他公司也会有所指导^_^。Mingle就应该是其中之一。 公司走的是CMMI的体系文件，即所谓的"重过程"管理，这样的过程对项目负责人的要求甚是严格，常常发生与QA之间的"你来我往"，甚至为一个无关轻重的文档"严词讨论"一番；再加上部门在过程工具上的选择比较"保守"，自己感觉部门的管理成本还是很高的，有些时候甚至感觉有些浪费。普通编程人员对各种文档也是有着"抵触"情绪的，特别是在"补"一些"写完即过时"的文档时更是无奈。 ...