如何将软件商店转换为TDD？

Question

我真的很想在我正在工作的商店里推动TDD开发。那里的许多老年人没有使用单元测试或者进行了数据库的单元测试。

我希望带来一些好的论据，培训书籍，可能的教练来缓解过渡。

Answer 1

我发现从开发人员那里推动TDD往往非常困难。我倾向于尽可能多地谈论TDD的好处，并尽可能地一点一点地介绍TDD的元素。

如果他们不介意，请在其中启动一个包含单元测试的新项目（管理人员很少考虑更多的测试覆盖率），并自己开始以这种方式开发。慢慢向团队的其他成员展示好处并尝试赢得一些转换。一旦你有其他一些开发人员，就开始推动管理层进行一些培训。

你也可以为其他开发者提供一些午餐学习知识。教学是最好的学习方式，你的意志有希望获得盟友。如果你很幸运，你可以和你的老板谈论购买披萨以获得午餐和每个人的好处。

Answer 2

就像Rob P说的那样 - 我也发现讲道以嘶哑的声音结束了我，没有人听。通过这样做并保持该部分可见，我得到了更快更广泛的结果。接受质疑，不要强迫它。鼓励和赞美，但不要鼓吹。

将其与发布测试结果结合起来并自动化 - 您可以发送一封电子邮件。您需要许多微妙的提醒来向人们展示您的方法有多好。

Answer 3

我认为将TDD主体潜入现有产品的好方法是开始编写针对错误的单元测试。通过这种方式，您可以慢慢开始为回归测试构建一组单元测试，这些测试成为项目的一个组成部分，特别是如果您可以将它们作为构建过程的一部分运行。

唯一的障碍是现有代码可能会对测试产生抵触情绪，但这只是进行重构的另一个借口。

一旦人们开始意识到这种势头将会增长的好处，但你需要开拓自己的方式。

Answer 4

虽然我不能告诉你什么会起作用，但我可以告诉你一些肯定不起作用的事情应该避免：

我会编写代码，你编写测试

这首先出现。人们认为，既然你对测试如此认真，那么你应该是编写测试的人。这根本不起作用，错过了重点。

你写的测试正在破坏，所以你必须修复它。

如果你开始为你的代码编写测试，那么其他人不可避免地会破坏这些测试。然后，如果你要求他们解决问题，他们会经常说这是你的责任。这不一定是他们的混蛋，可能只是他们不理解这个过程。这是您需要管理备份的地方。

我刚刚开始，每个人都会关注。

像其他人所说，TDD没有管理支持是非常困难的。如果有任何开发者不“喝冷饮”那么他们将不断打破你的测试，而不是关心。如果你不能让他们相信，那么你需要管理层告诉他们这是他们的工作。

最终带给我的是由于太多错误而导致项目崩溃。它使我确信我做了一些根本错误的事情。一个小小的研究让我进行了自动化测试，并且在一点点决心的情况下，我自学了基础知识。也许和你的同伴谈论类似的项目（我们都至少有一个......）将帮助他们意识到他们可能想尝试一些新的东西。

Answer 5

以身作则：

• 在您编写的所有代码上使用TDD
• 在您有机会时立即向他们展示好处（通过单元测试或在单元测试环境中重新创建的事件检测到回归）
• 提供“干净的代码”
• 向其他人提出帮助
• 不要教条 - TDD不是银弹
• 使您的单元测试可见：它们应与他们测试的代码一起编译

Answer 6

如果项目没有足够的单元测试，您可以指出问题数据库中的错误，如果进行了单元测试，可能会避免这些错误。

至于推动TDD或其他一些代码宗教，请不要打扰。

对于某些人（以及某些类型的代码），TDD很棒。有些人不这样做，也没有从先测试中受益。只要他们不完全避免测试，我认为这不重要。

Answer 7

带来“自下而上”的TDD面临的一个巨大挑战是，当推动推动时（因为它不可避免地会在截止日期临近时），管理层将过度强调测试：“我们可以我们不能测试！我们必须完成这个项目！“

当然，正是这种情况（最后期限迫在眉睫，重大积压，进展不顺利，承诺，导致快速转移的优先事项和任务）TDD的好处真正起作用。管理层超越它，项目/ iteration开始在相同的旧同一时代分崩离析，管理层回顾并说“我们尝试过TDD，它根本没有帮助。”