unit-testing - 如何说服团队中的程序员进行 TDD？

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用资料或专业知识的支持，但这个问题可能会引发辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center寻求指导。




9年前关闭。




我知道这个问题:https://stackoverflow.com/questions/428691/how-to-encourage-implementation-of-tdd
在我的团队中，我们编写了很多单元测试。但是，通常程序员倾向于在编写代码后编写单元测试。因此，我们首先完成模块功能，然后编写测试。大多数模块的覆盖率约为 70%。我曾尝试说服我的技术经理和我的团队成员进行纯 TDD，其中我们首先编写测试然后编写代码，但徒劳无功。我认为首先编写测试可以让我们更好地发现设计。我是不是很挑剔，尤其是当我们的覆盖率很高时？如果这个问题的答案是否定的，那么我如何与人们交谈以采用测试优先的方法。
编辑:我认为在编写代码之后编写测试是一件更容易的事情。我团队中的人已经习惯了这样做，并且反对任何改变。

Answer 1

我不知道有很多东西可以告诉人们让他们相信 TDD 的值(value)。您可以引用专家告诉我们的内容以及您自己的个人经历，但如果人们不愿意尝试，那么您与他们分享这些信息会有所帮助的可能性很小。

我对 TDD 的体验基本上是，它听起来是一个非常好的主意，但它从来没有真正按照预期的方式实现。然后有一天，我在一项新任务上再次尝试了它，最终得到了一个比我想象的更简单的问题解决方案，这完全是因为我使用了 TDD。我认为当开发人员拥有这种经验时，它会改变他们看待事物的方式，并使他们更愿意在其他情况下尝试。

挑战在于能够向其他开发人员证明这一点。您可能能够做到这一点的一种方法是使用像 this one 这样的 TDD Kata。来自 Roy Osherove(他在他的 TDD 硕士类(class)中使用它)。它专门用于展示小步骤工作的值(value)，只实现使每个测试通过所需的代码。这可能会向人们展示该过程是如何工作的，并使他们更愿意尝试一下。

还有一个编码练习，我听说你给两个开发人员小组/团队一个相当简单的任务，并要求其中一个小组使用 TDD，并确保他们遵循“可能工作的最简单的事情”规则，而另一支球队随心所欲地做事。然后，一旦完成，您让团队切换任务，但丢弃每个团队编写的代码，只留下测试。然后，团队应该为任务重新创建代码。通常，您会发现继承 TDD 代码的团队更容易做到这一点。

尽管如此，我认为你个人能做的最好的事情就是尽可能多地自己开始做 TDD。这有可能为您提供一些非常具体的引用资料，说明在当前项目的上下文中，TDD 在何处以及如何被证明是有益的。特别是如果您进行代码审查，您的同行可能会注意到您编写的 TDD 代码比没有 TDD 编写的代码更简洁，更易于维护。您的 QA 团队也可能会注意到代码质量的差异，这是您经常听到的关于迁移到 TDD 的公司的事情之一。