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

Question

我真的很想在我工作的商店内推动 TDD 开发。那里的许多前辈没有从事过单元测试，也没有做过涉及数据库的单元测试。

我很想带来一些好的论据、培训书籍、可能的教练来缓解过渡。

score 14 · Accepted Answer

我发现通常很难从开发人员那里推动 TDD。我倾向于做的是尽可能多地谈论TDD的好处，并在可能的情况下，自己一点一点地介绍TDD的元素。

如果他们不介意，就开始一个包含单元测试的新项目（经理很少介意更多的测试覆盖率），然后自己开始开发。慢慢地向团队的其他成员展示好处，并尝试赢得一些皈依者。一旦你身边有一些其他开发人员，就开始推动管理人员进行一些培训。

您还可以为其他开发人员提供一些关于它的午餐学习。教学是最好的学习方式，您将有望获得盟友。如果你幸运的话，你可以说服你的老板为午餐学习买披萨，这样每个人都会受益。

score 3 · Accepted Answer

就像 Rob P 说的那样——我还发现讲道以嘶哑的声音结束了我，没有人在听。通过这样做并保持该部分可见，我可以更快、更广泛地获得结果。对质疑持开放态度，不要强迫它。鼓励和赞美，但不要说教。

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

score 3 · Accepted Answer

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

唯一的障碍是现有代码可能无法测试，但这只是进行重构的另一个借口。

一旦人们开始意识到好处，势头就会增长，但你需要开拓道路。

score 3 · Accepted Answer

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

我写代码，你写测试

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

您编写了破坏性的测试，因此您必须修复它。

如果您开始为您的代码编写测试，则不可避免地会有其他人破坏这些测试。然后，如果您要求他们修复它，他们通常会说这是您的责任。这不一定是他们是个混蛋，可能只是他们不了解这个过程。这是您需要管理备份的地方。

我就开始吧，大家都跟着。

正如其他人所说，没有管理支持的 TDD 非常困难。如果有任何开发人员不“喝 Cool-Aid”，那么他们将不断地破坏您的测试并且不在乎。如果你不能让他们相信，那么你需要管理层告诉他们这是他们的工作。

最终让我兴奋的是，看到一个项目由于太多的错误而崩溃。它使我确信我做的事情根本上是错误的。一项小小的研究让我接触到了自动化测试，并带着一点决心自学了基础知识。也许与您的开发人员同事讨论类似的项目（我们都至少有一个......）将帮助他们意识到他们可能想尝试一些新的东西。

score 2 · Accepted Answer

以身作则：

score 1 · Accepted Answer

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

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

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

score 0 · Accepted Answer

“自下而上”带来的 TDD 的一个巨大挑战是，当迫在眉睫时（就像最后期限临近时不可避免的那样），管理层将忽略对测试的重视：“我们负担不起测试！我们必须完成这个项目！

当然，这正是 TDD 的好处真正发挥作用的情况（最后期限迫在眉睫，大量积压，进度未按承诺进行，导致优先级和任务迅速转移）。管理压倒它，项目/迭代开始以同样的方式分崩离析，管理层回头说：“我们尝试了 TDD，但它根本没有帮助。”

7 回答 7