我真的很想在我正在工作的商店里推动TDD开发。那里的许多老年人没有使用单元测试或者进行了数据库的单元测试。
我希望带来一些好的论据，培训书籍，可能的教练来缓解过渡。
答案 0 :(得分：14)
我发现从开发人员那里推动TDD往往非常困难。我倾向于尽可能多地谈论TDD的好处，并尽可能地一点一点地介绍TDD的元素。
如果他们不介意，请在其中启动一个包含单元测试的新项目（管理人员很少考虑更多的测试覆盖率），并自己开始以这种方式开发。慢慢向团队的其他成员展示好处并尝试赢得一些转换。一旦你有其他一些开发人员，就开始推动管理层进行一些培训。
你也可以为其他开发者提供一些午餐学习知识。教学是最好的学习方式，你的意志有希望获得盟友。如果你很幸运，你可以和你的老板谈论购买披萨以获得午餐和每个人的好处。
答案 1 :(得分：3)
就像Rob P说的那样 - 我也发现讲道以嘶哑的声音结束了我，没有人听。通过这样做并保持该部分可见，我得到了更快更广泛的结果。接受质疑，不要强迫它。鼓励和赞美，但不要鼓吹。
将其与发布测试结果结合起来并自动化 - 您可以发送一封电子邮件。您需要许多微妙的提醒来向人们展示您的方法有多好。
答案 2 :(得分：3)
我认为将TDD主体潜入现有产品的好方法是开始编写针对错误的单元测试。通过这种方式，您可以慢慢开始为回归测试构建一组单元测试，这些测试成为项目的一个组成部分，特别是如果您可以将它们作为构建过程的一部分运行。
唯一的障碍是现有代码可能会对测试产生抵触情绪，但这只是进行重构的另一个借口。
一旦人们开始意识到这种势头将会增长的好处，但你需要开拓自己的方式。
答案 3 :(得分：3)
虽然我不能告诉你什么会起作用，但我可以告诉你一些肯定不起作用的事情应该避免：
我会编写代码，你编写测试
这首先出现。人们认为，既然你对测试如此认真，那么你应该是编写测试的人。这根本不起作用，错过了重点。
你写的测试正在破坏，所以你必须修复它。
如果你开始为你的代码编写测试，那么其他人不可避免地会破坏这些测试。然后，如果你要求他们解决问题，他们会经常说这是你的责任。这不一定是他们的混蛋，可能只是他们不理解这个过程。这是您需要管理备份的地方。
我刚刚开始，每个人都会关注。
像其他人所说，TDD没有管理支持是非常困难的。如果有任何开发者不“喝冷饮”那么他们将不断打破你的测试，而不是关心。如果你不能让他们相信，那么你需要管理层告诉他们这是他们的工作。最终带给我的是由于太多错误而导致项目崩溃。它使我确信我做了一些根本错误的事情。一个小小的研究让我进行了自动化测试，并且在一点点决心的情况下，我自学了基础知识。也许和你的同伴谈论类似的项目（我们都至少有一个......）将帮助他们意识到他们可能想尝试一些新的东西。
答案 4 :(得分：2)
以身作则：
答案 5 :(得分：1)
如果项目没有足够的单元测试，您可以指出问题数据库中的错误，如果进行了单元测试，可能会避免这些错误。
至于推动TDD或其他一些代码宗教，请不要打扰。
对于某些人（以及某些类型的代码），TDD很棒。有些人不这样做，也没有从先测试中受益。只要他们不完全避免测试，我认为这不重要。
答案 6 :(得分：0)
当然，正是这种情况（最后期限迫在眉睫，重大积压，进展不顺利，承诺，导致快速转移的优先事项和任务）TDD的好处真正起作用。管理层超越它，项目/ iteration开始在相同的旧同一时代分崩离析，管理层回顾并说“我们尝试过TDD，它根本没有帮助。”