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

Question

我正在与一个新团队一起工作，这个团队历史上没有做过任何单元测试。我的目标是团队最终采用TDD (测试驱动开发)作为他们的自然过程。但是由于TDD对于一个非单元测试团队来说是一个激进的思维转变，我想我应该从编写代码后的单元测试开始。

有没有人遇到过类似的情况？当团队还没有进行任何单元测试时，有什么有效的方法可以让团队适应TDD呢？在几个步骤中这样做有意义吗？还是我们应该一次跳进去面对所有的成长痛苦？？

编辑

为了澄清起见，团队中没有人(除了我以外)有任何单元测试公开/经验。我们计划使用Visual中内置的单元测试功能。

Answer 1

实践中存在的缺陷/缺陷.

这是一个非常艰难的局面。我以前从未一事无成地到过TDD，但根据我的经验，让一个团队从没有单元测试到主动编写它们是一种非常“一步一步”的方法。

首先，让他们能够轻松地编写单元测试，并真正知道他们是什么以及他们的好处。对于我的团队来说，最好是为现有的bug编写单元测试。当前系统中的bug有两件事，您需要教人们如何编写好单元测试：

1. 一个预期的前提和后条件
2. 目前并不是预期的结果，并且违反了这一先决条件/后条件。

这为议员提供了非常具体的实践例子。他们可以在修复错误之前编写一个测试，这样它就失败了。然后，他们可以修复代码，使其通过，并修复错误。一旦他们对此感到满意，那么您就可以让他们在剩下的时间里编写单元测试，而无需预先编写代码，然后编写新的代码以使他们的测试通过。

我认为诀窍是给他们一些东西，在那里有明确的方法，前后条件。如果对方法的需求是模糊的，那么即使是经验丰富的TDD人员也很难确切地知道从哪里开始。一步一步，你就会到那儿的。祝好运!

Answer 2

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

1. 解释，解释，解释。你不想让你的团队写测试。你想让你的团队想要写测试。这意味着他们应该充分理解他们为什么要这么做，有什么好处，以及这将如何使他们的工作变得容易得多。红色，绿色，重构，写一个回归测试，以证明一个错误已经修复，等等。你必须说服他们，整个事情是有意义的，然后你要求他们写任何代码。
2. 进行真实的测试(首先测试，然后是代码)。在代码之后编写测试几乎没有任何意义，因为您将永远不会知道它们是否实际工作(而且人们确实会编写错误的测试用例)。我的直觉是，从没有测试到先进行测试所需的精力远远少于您需要通过代码先通过代码进行测试到先进行测试的程度，所以您最好跳过中间一步。
3. 从回归测试开始。这些东西很容易理解，而且能给人即时的满足。当然，这假设代码是正确模块化的，并且易于测试。如果没有，跳过这一步。
4. 迈出一小步。TDD需要一段时间才能被使用，一开始可能会令人沮丧。尝试在一个全新的项目或组件中引入测试，理想的情况是:一些不太重要的东西。您想要不惜一切代价避免出现这样的情况:有一些非常重要的事情需要尽快完成，而程序员觉得TDD正在阻碍您的工作。
5. 当团队开始感到舒适时，以TDD方式编写所有新功能。这取决于项目的大小，但经过一段时间之后，您应该会得到相当好的覆盖率，您的项目的一些遗留部分将以旧的方式编写。
6. 到目前为止，团队应该已经理解并接受了TDD，而遗留(非TDD)的东西应该被认为是很难处理的和烦人的。把它重新分解:大多数人都会很高兴地去做。

还有一些重要的问题：

• 确保您正在使用可用的最佳测试框架。如果人们不得不与写得不好的库进行交互，那么要说服人们做TDD就会困难得多。
• 确保测试易于运行，并且不会花费太多时间来完成(或者欺骗，例如，使用内存中的数据库进行测试)。
• 安装一些连续的集成软件，以便立即发现故障测试。

Answer 3

使用TDD的一种方法是首先编写集成测试。稍后介绍测试接缝和真正的单元测试。

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

集成测试可以为您提供最初的覆盖率。每次出现回归或生产问题时，请在代码中修复它，并用测试覆盖该代码。一旦你有足够的安全网提供这样的测试，你可以引入单元测试更细粒度，孤立的组件和/或类的系统。