（这不是一个调查 TDD 优点的问题。还有其他地方可以进行此类讨论。提前致谢。）
我遇到过太多不熟悉该技术的开发人员，他们也报告对测试驱动开发和 NUnit 不满意。
我听到一些负面评论，例如：
“我不喜欢 NUnit。 我在一年前尝试过，但我忘记了如何使用它。让我们使用我刚刚编写的这个 Windows 窗体应用程序作为测试工具。无论如何，测试代码都是一次性代码，什么是有什么区别？反正我过去的方法还不错。
“我对 TDD 持保留意见。在我们的最后一个项目中（顺便说一句，这是我第一次也是唯一一次使用 TDD 的项目经验），我们甚至不知道设计是什么。”
“更多的代码注释很糟糕？你疯了吗？如果你不介意的话，我真的有一些工作要做。” （来自老派的更多评论是更好的评论，你永远不会有太多评论。）
当一个新手抱怨说 TDD 在他们的第一个使用 TDD 的项目中“没有工作”令他们满意时，是 TDD 真的让他们失望了，还是开发人员自己的技能还不足以获得好的结果？
如果他们不恨我这么说，我怎么能沟通呢？
问题的关键是，可以通过哪些外交手段与开发人员进行沟通，以鼓励他们更诚实地评估自己在新开发技术方面的新生和不足的能力，而不会危及我们重要的工作关系？
通常，许多开发人员显然还没有掌握 TDD 的许多重要元素，以便在他们的第一个项目中很好地完成它。
例如，与我交谈过的开发社区中的抱怨者很典型：
甚至从未尝试查看或记住代码异味列表。
甚至从未尝试研究重构目录，也从未在实际项目或玩具项目中实践过重构目录。对于某些人来说，可能需要学习更多的 OOP，以便能够很好地进行重构。重构不仅仅是“重命名方法”和“重命名变量”，它们显示为 Visual Studio 2005 重构菜单上的项目。
甚至从未尝试过研究或参与使用紧急设计（通过重构）实现的实际项目，与预先使用设计完成整个项目相比，与仅在编写代码后才编写单元测试的整个项目相比，并且知道差异和它们之间的权衡和适用性。
他们似乎都曾经使用过 NUnit，所以无论他们用它做什么，都是 TDD，天哪，他们似乎认为。NUnit 或单元测试的存在并不意味着 TDD，但他们还不够了解，甚至不知道这一点。
这些都是聪明人。开发人员是聪明人，因为这是进入整个职业的门槛。否则你不能在这个职业中呆太久。当然，如果他们花时间研究这些材料，他们就可以理解。
当他们的经验和知识的总和显然太弱以至于无法对方法或其结果进行评估时，人们怎么能诚实地告诉自己方法论很弱呢？
然而他们确实……我相信这是一种自我保护的行为。或者是懒惰。如果你甚至无法从 Fowler 的重构书目录中说出三个重构，或者如果你无法说出几个代码异味，那么你就是重构的新手，并且可能也是整个 TDD 方法论，以及你所谓的 1或者2个项目经验显然是不够的。
我可以对人们说些什么，或者我可以引导人们关注哪些材料，以让他们做必要的事情来更多地了解 TDD 成功所依赖的技能，例如：
- 单元测试，
- 重构，
- 设计模式，
- OO设计和分析？
关于这些主题中的每一个都有整本书，有些非常好。也许也有一些更容易接受的学习技巧？我可以以身作则，但我自己给他们的时间是有限的，而且我还不是所有这些技术的黑带。
此外，他们一起去。没有彼此，它们就不能很好地工作。单元测试和重构就像花生酱和果冻一样。如果你不能 grep 单元测试，那么你的重构肯定不会有很好的结果！（问我为什么如果你还不知道，我很乐意向新人解释。）
同样重要的是，无论我做什么或说什么，都不会适得其反：
我不能让我的同事疏远 TDD 概念；此外，我绝不能疏远我的同事。 在接下来的许多年里，我将不得不每周与他们一起工作。
很难不让其他长期资深的开发人员感到不安，他们已经证明自己在编程的其他方面非常精通。他们理所当然地为自己过去的成就感到自豪，但是他们的自尊心或他们对编程中所有事情的掌握的自我概念几乎是无法克服的，而不会伤害他们的感情。一些高级开发人员还没有准备好面对他们不知道应该向其他人学习的一些新技术。在编程方面，高级开发人员可以更习惯和更自在地成为房间里的专家，有时他们要求被视为专家，即使在涉及 TDD 和相关技术和技术时这完全不现实。
我很高兴地报告说，在编写结构化自动化单元测试方面，我在扭转我们的常驻“反对者”之一方面取得了相当大的成功，一种方法是与他们一对一地使用结对编程。我猜，结对编程为学员提供了一些现实生活中的例子和经验，以及更有经验和知识渊博的从业者的直接指导。
但是结对编程是不够的。他们需要学习更多的重构、代码异味、OOP 概念和 OOD&A 概念，而我无法在一个项目中教授所有这些，甚至不能接近。