单元测试新手团队需要进行单元测试

我正在与一个新的团队合作，该团队历来没有进行任何单元测试。我的目标是让团队最终采用TDD（测试驱动开发）作为自然过程。但是由于TDD对于非单元测试团队来说是一种根本性的转变，我想我应该从编码后编写单元测试开始。

有人遇到过类似情况吗？什么是让团队在未进行任何单元测试时对TDD感到满意的有效方法？分两步进行是否有意义？还是我们应该立即潜水并立即面对所有不断增长的痛苦？

编辑

只是为了澄清起见，团队中除我本人之外，没有任何人可以测试暴露/经验的任何单元。我们计划使用Visual Studio中内置的单元测试功能。

练习现有的错误/缺陷。

这是一个非常艰难的情况。我从来没有从无到有地发展到TDD，但是根据我的经验，让团队从没有单元测试过渡到主动编写它们是一次非常“一步一步”的方法。

首先，让他们舒适地编写单元测试并真正了解它们是什么以及它们的好处。对于我的团队来说，最好为现有的错误编写单元测试。当前系统中的错误有两点需要您教人如何良好地编写单元测试：

1. 预期的前提条件和后置条件
2. 当前不是预期的结果并且违反了该先决条件/后置条件的结果

这为成员提供了非常具体的实践示例。他们可以在修复错误之前编写测试，以使测试失败。然后，他们可以修复代码，使其通过，并修复错误。一旦他们对此感到满意，那么您可以按照其他方式进行操作，以便他们可以在不预先编写任何代码的情况下编写单元测试，然后编写新代码以使测试通过。

我认为，诀窍是为他们提供一些在明确的方法前/后条件的地方进行实践的方法。如果对方法的要求模糊不清，那么即使是经验丰富的TDD人员也很难确切知道从哪里开始。及时采取措施，您将到达那里。祝好运！

我设法说服我的整个公司改用TDD。这并不容易，但是值得付出努力：过渡后代码的质量提高了，现在没有人能想到回到可怕的牛仔时代。

1. 解释，解释，解释。您不希望您的团队编写测试。您希望您的团队要编写测试。这意味着他们应该充分理解为什么要这样做，有什么好处以及如何使他们的工作更轻松。Red，Green，Refactor，编写回归测试以证明错误已得到修复，等等。在要求他们编写任何代码之前，必须说服他们整个事情才有意义。

2. 追求真实（首先测试，然后编码）。在代码之后编写测试几乎没有任何意义，因为您永远不会知道它们是否真正起作用（并且人们确实编写了有缺陷的测试用例）。我的直觉是，从无测试到首先进行测试所需的工作量要比从无代码先通过代码先进行测试所需的工作量少得多，因此您也可以跳过中间步骤。

3. 从回归测试开始。这些很容易理解，并且可以立即得到满足。当然，这假设代码已正确模块化并易于测试。如果不是，请跳过此步骤。

4. 采取婴儿的步骤。TDD需要花费一些时间才能使用，起初可能会感到沮丧。最好将测试引入全新的项目或组件中，这不是很重要。您想不惜一切代价避免这种情况，那就是要真正快速地完成一些非常重要的事情，而程序员却认为TDD正在妨碍您。

5. 当团队开始感到舒适时，请以TDD方式编写所有新功能。这取决于项目的大小，但是一段时间后，您应该会获得很好的覆盖，只用旧的方式编写项目的某些旧部分。

6. 至此，团队应该已经理解并接受了TDD，而遗留（非TDD）的东西应该被认为很难并且令人讨厌。重构它：大多数pople都会乐在其中。

其他一些重要点：

• 确保您使用的是最好的测试框架。如果人们必须与编写得不好的库进行交互，要说服人们进行TDD将会更加困难。

• 确保测试易于运行，并且不会花费太多时间来完成（或作弊，例如，通过使用内存数据库进行测试）。

• 设置一些持续集成软件，以便立即发现损坏的测试。

熟悉TDD的一种方法是先编写集成测试。稍后介绍测试接缝和真实单元测试。

编码后编写单元测试的问题在于，代码不一定经过精心设计以可测试。您可能需要进行一些重构或重新设计以引入测试接缝。但是，如果没有任何类型的测试范围，如何安全地重构或重新设计？

集成测试最初可以为您提供覆盖范围。每次遇到回归或生产问题时，请将其修复在代码中，并通过测试覆盖该代码。一旦有了足够的由此类测试提供的安全网，就可以对系统的更细粒度，更孤立的组件和/或类进行单元测试。

TDD很难实施，对于每个开发团队而言，TDD并非始终是最佳选择。在我之前的工作中，团队主要致力于TDD。我们的开发模型完全是使用敏捷开发方法的TDD.Testing通过Visual Studio单元测试完成。

如果开发人员没有为他/她的功能编写任何单元测试，他们将在技术主管方面遇到麻烦。此外，如果有人签入了损坏的版本或进行了任何单元测试，则开发人员将需要修复所有问题，并向团队资金罐中增加1美元。

只需添加一小件事，即可可视化该过程。使连续集成自动运行测试并检查代码覆盖率。在每个人都可以看到的某些起始页面上列出最完整的经过测试的模块。那应该使团队竞争不断进行。

我从没有JUnit经验直接转到TDD，这一经验使TDD的价值显而易见。我对单元测试非常感激，以至于我很快成为该方法的推广者

我参加过的团队没有进行任何单元测试，但是它是引入的，现在几乎可以进行一些测试了。我建议您探索一下您的团队对单元测试的基础了解得如何，以及您希望将哪些工具引入这里？

就我而言，它是为某些.Net代码引入nUnit，这些代码是业务逻辑，用户界面和后端功能的组合。我建议您看看是否有一些人比其他人更愿意去实现它，以便团队中的几个人都可以得到它，并且它的传播要比试图让每个人都受益的另一面更好跳上这个。通过让一些人首先做好它，可以进行一些交叉训练，以便对拿起它的人进行测试，以了解他们如何将其教给其他人。

另一点是考虑引进那些具有更多专业知识的人员，以在某种程度上证明这一点。我将Thoughtworks带入到我的工作中，向我们展示一些确实被广泛采用的东西，而其他部分却没那么多，但是我认为在大多数地方都是如此。