答案 0 :(得分：17)
几乎不可能将你的想法强加给别人，让他们被接受。您可以使用自己的方法，也许其他人希望在他们看到好结果时学习。你只是期待像TDD，结对编程等这些东西神奇地获益吗？
你也没有指出你的角色。 （或者至少我没有找到它）
您可以尝试不同的方法：
提供关于TDDor nunit的午餐时间研讨会。显示您看到的好处。为开发人员/公司提供真实的例子和真正的好处。如果没有这些，你将无法接受观众。
至少你有自己编写测试工具的人 - 这是一件好事。我会赞美这一点并要求查看更多内容。
询问开发人员他们对此问题的看法，他们想要什么样的测试或公司如何改进。你必须停止强加你的想法，让它来自他们。
编辑 - 来自经验
多年前我有类似的经历。我读过许多关于过程和开发软件的正确方法的书籍（tm），然后告诉大家我看到了正确的做事方式......没有人想听到它。我意识到我冒着被边缘化的风险并没有真正得到任何有用的东西。所以我只是闭嘴并在我刚刚领导的小组中实施了一些好的做法。大约4个月后，人们开始询问我们我们如何获得我们提供的结果。
而不是寻找其他人来找我们。 （这不是我的计划，但回想起来它是有意义的。人们想要结果，而不是热空气）
答案 1 :(得分：10)
将你的问题提炼成一行：
And how can I communicate that without them hating me for saying it?
作为一个如此优秀的开发者，你赢得他们的尊重，然后他们会倾听。这里真的没有任何捷径。我的建议是成为一名更好的开发者和更好的传道者。如果你向那些想要教学的人学习，那么他们可能会开始向你学习。
在充分尊重的情况下，您对TDD的态度是相当虔诚的。这也无济于事。将此与TDD所涉及的大文化变革相结合，你成功传福音的机会开始急剧缩小。
答案 2 :(得分：9)
我认为TDD最大的问题是人们会专注于这些测试。
这些测试在某种程度上并不重要。通过所有测试只能证明您已通过所有测试。此外，您可以通过所有测试，完全覆盖，并且仍然有一个无人问津的糟糕，无法使用的应用程序。
通过100％的测试和制作出色的产品之间的差距就是这个行业的一点点。
另外，TDD只是指定设计的另一种方式。这是TDD的重要部分，将设计锁定到某种程度。
答案 3 :(得分：7)
也许不是TDD不是问题，但您是否考虑过真的是否适合您正在使用的环境，以及您正在处理的项目类型？您还没有提到您目前遇到的问题（甚至您当前使用的方法和实践）以及采用TDD的原因可以解决这些问题。你确定你所看到的阻力不是因为抵制变化，而是因为你试图解决一个不存在的问题吗？
TDD并非适用于所有环境。这肯定是因为我工作得太快，因为我们的工作太快了，通常会在每次迭代中大致开始编写并改进/更改/重写的规范，因此我们不会拥有任何定义了大多数时间要测试的行为。此外，我们已经开发了一些实践，这意味着代码在很多情况下根本不需要测试，因为该方法是一个单行程，静态类型检查确保必须工作。
你的帖子中有很多评论标记你可能是相对缺乏经验的人，并且已经锁定了一种方法，你认为这种方法可以解决所有问题，如果他们的同事必须学习要跟上你的步伐。不幸的是，在软件开发方面没有灵丹妙药，如果他们是具有丰富经验的高级开发人员，并且他们不相信TDD是合适的，那么可能只是，值得倾听他们
你也应该意识到TDD不是重构的先决条件，就像那些喜欢“红绿色重构”咒语的人一样。如果您正在重构一个小区域并且知道它会影响什么，并且可以轻松地手动测试，那么您可以在重构期间和之后手动测试该区域。
答案 4 :(得分：4)
只是扮演魔鬼的拥护者，你为什么这么确定TDD真的有效？个人经验？实证研究？
以下两项研究报告了TDD的阳性结果：
两个没有定论：
我不确定将方法呈现为完美无缺是一个好主意。它可能是有效的一种方法。据我们所知，还有更好的方法。也许邀请所有开发人员设计一个非常适合您组织的混合方法。
答案 5 :(得分：4)
没有人喜欢被告知他们在专业方面不够专业。这个人越高级，采用新的方法就越耐用，让他们觉得自己像个新手。
我在促进测试方面取得的最大成功是创建测试覆盖率的图形报告，并将其发布给团队（或者将内部团队网页连接到持续集成测试报告）。是的，测试覆盖率不是衡量质量的总量度，但它是一种非常简单的方式来显示谁在编写测试，哪些不是。
让合议庭竞争，以确定谁可以保持最高百分比的代码覆盖率。人们喜欢竞争。当他们落伍，或者如果他们用不可测试的“代码口袋”编写代码时，也许他们会考虑重构它的方法，以便他们的测试确实显示代码覆盖率。如果他们不喜欢被“教育”，那么让他们自己发现重构技术。这样他们就可以继续保持聪明。
或者还有棕色的午餐，人们可以展示他们为实现更大的可测性而进行的一些巧妙的重构。人们喜欢炫耀！他们不仅仅表现出他们的无知。
距离TDD还有很长的路要走，但至少在改善QC方面取得了一些进展。一旦他们对这些工具和一些简单的重构方法更加熟悉，那么你可以逐步引入一些更高级的东西：结对编程......代码审查......检测代码味道......跟踪测试要求。 然后你可以绕过TDD。
正如Steven Lowe在这篇帖子中所说，罗马不是一天建成的。
答案 6 :(得分：3)
你真正的问题是“如何说服我的同事去尝试一些新事物？”
这是一个非常好的问题，抱歉这真的很难。几年前我和Alistair Cockburn就这个问题进行过一次谈话，我发布了the slides，但是没有写过文字，但我可以在这里给出一个简短的版本。
您熟悉Technology Adoption Lifecyle还是Crossing the Chasm？这些涉及人口群体和他们改变的动机。与您的情况相关的关键想法是，只有位于鸿沟左侧的人 - 创新者和早期采用者 - 才有兴趣改变尝试并使事情变得更好。在鸿沟右侧的人 - 大多数人 - 更容易抵抗变化，当他们改变时，这与左侧人不同。结果两个小组倾向于互相讨论。
你是鸿沟的一员。你的大学是在右边。如果你继续给他们你的理由改变你就不会说服他们。
说服他们尝试新事物的是什么，如果它提供了可靠的承诺，可以减轻他们感受到的当前痛苦。
谈论TDD如何更好以及你应该做什么，而你正在谈论它们。
谈论TDD如何解决当前的痛苦，你会引起他们的注意。
杀手部分？如果没有当前的痛苦，你不太可能让他们改变，期间。
这就是选项“改变您的组织或改变您的组织”的原因。
祝你好运！答案 7 :(得分：1)
继续配对并树立良好榜样，其他人将看到光明并跟随你的主导
你可以带马去喝水，但你不能让他喝水。如果你将他推入水中，他将要么淹死要么逃跑。 ; - ）答案 8 :(得分：1)
更有可能的问题是，在习惯TDD风格和创建TDD所需文化的同时降低生产力是否是我认为出错的地方。
这些高级开发人员的生产力是否会大幅下降，这对每个人都是可以接受的？如果你能感觉到每个人都可以重新学习如何开发代码，那么你可能会有一些东西，但请记住，大多数开发人员都有自己的个人优化来编写我认为TDD将会删除的代码，例如：如果你使用严格的TDD形式，那么猜测并然后解决这些错误可能是一种常见的方法，并不能完全削减它。
答案 9 :(得分：1)
引起我注意的第一件事是：“无论如何，测试代码都是一次性代码”。我的意思是，哇。
当然，TDD的情况恰恰相反。您的测试成为回归防火墙，并允许您自信地重构和添加功能。
根据我的经验，你必须要有两件事情才能将这样的做法引入一种抵抗（但并非完全顽固）的公司文化：你必须有一个经理强制要求的实践，你必须拥有团队中的工程师之前已经完成了工作。这个工程师的时间必须在实际的项目工作和指导之间进行分配，指导采取小组演示，代码审查和（支持）对结对编程的形式，直接向人们展示如何将实践应用于他们试图解决的问题。
除了让它在过去工作之外，这位工程师还必须是一名技术熟练的老师（因为你要求人们改变，大多数人会将其视为个人攻击）具有非威胁性的个性和教学方法
祝你好运。
答案 10 :(得分：1)
这需要时间，而且需要（缺乏更好的词）营销。 TDD（或一般的单元测试）在团队成员尊重的人提倡之前不会被接受。
如果您还不是团队中最受尊敬的成员之一，那么您要么必须成为一名（通过展示卓越性），要么专注于一个或多个技术领导者，并将他们带到你的身边。
当然，每个人都不同，你必须弄清楚如何向各个部落领导人展示TDD，以便他们尽可能地接受这个想法。
绝对必须发生的一件事是，必须非常容易地创建测试并运行它们。如果你从一个人们对TDD的优势持怀疑态度的位置开始，那么尝试它的道路上的任何小问题将会非常激励。
答案 11 :(得分：0)
请参阅以下链接，了解使用TDD解决问题世界问题的示例方法
https://stackoverflow.com/a/15163004/2124293
你可以过去看看你的世界简约，但看看你可以从思考过程中得到什么