如何解释单元测试的价值

Question

我想向我的同事介绍单元测试(和一般测试)的概念；现在根本没有测试，通过UI实际执行任务来查看所需的结果来进行测试。正如您可能想象的那样，代码与确切的实现紧密耦合--甚至导致代码应该在类中被复制和粘贴到跨方法的系统中。

由于需求的变化，我被要求修改我以前写过的模块，这个模块是相当松散耦合的(不是我想要的那么多，而是尽可能地不需要引入许多其他概念)。我决定在修改后的代码中包含一组单元测试，以“证明”它按照预期工作，并演示测试是如何工作的；我没有遵循真正的TDD，因为已经编写了一些代码，但我希望为我必须创建的新代码遵循一些TDD概念。

现在，我肯定会被问到为什么我要花上一两天的时间来编写代码，因为我将与之交互的部分内容已经存在于系统中(尽管没有任何测试，也没有非常紧密的耦合)，当我检查代码时，我会被问到这个“测试”项目是什么。我可以解释测试的基本知识，但我不能以其他人理解的方式解释实际的好处(因为他们认为测试需要您自己运行应用程序，因为通常实际的UI在确定该功能“工作”与否时很重要)。他们不理解松耦合的概念(很明显，没有什么是松耦合的；在我编写的代码之外甚至没有任何接口)，所以尝试将其作为一种好处可能会给我带来“嗯？”看起来，我不可能像我想的那样松散，而不需要重做几个现有的模块，并可能引入某种IoC容器，这将被看作是浪费时间，而不是“编程”。

有人对我如何指出这段代码并说“我们应该开始创建单元测试”有什么建议吗？“写作测试迫使你写好代码。”这可能意味着代码，除了我的代码是坏的)或者没有使它看起来像是浪费时间，没有增加任何真正的价值？

Answer 1

我想向我的同事介绍单元测试(和一般测试)的概念。

我认为最好从实际出发，而不是从概念方面着手。当然，如果你在非正式的讨论中发现你的同事和/或管理层对单元测试感兴趣，那就更好了--那么你可以从网络上搜索一些具体的经验/证据，整理一个简短的培训等等。然而，从你的描述来看，你的队友似乎对这个奇怪的新想法并不十分开放。

在这种情况下，我只是开始编写我的小单元测试，而不想首先向任何人解释太多。每当我更改代码时，添加几个代码，而不试图彻底覆盖所有代码(这将花费过多的时间)。理想的情况是，如果我能够在他们注意到我正在编写单元测试时找到一个很好的平衡，我可能已经有了大量的测试套件，以及一些具体的结果(比如“使用这个测试用例，我成功地捕获了上周的更改引入的一个bug，否则它就会滑到QA/production中去”)。这将证明这些测试对任何严肃的开发人员都是有价值的。

之后，我就可以开始解释单元测试的长期好处了，比如

• 它证明了代码在任何时间、地点、瞬间和自动地工作，而这反过来又是可行的。
• 给重构带来信心，改善设计和更好的可维护性，
• 如果某件东西坏了，单元测试给你(几乎)即时反馈，而不是几天或几周的延迟，如果错误是由一个单独的QA部门捕获的。这通常使您能够在几秒钟内修复错误，而不是调试几个小时/天，代码早已从短期内存中删除。

还请参阅以下相关线程：自动化单元测试、集成测试或验收测试。

之前的一个例子是：什么是单元测试？

Answer 2

无恐惧的再因素

作为一个稍微不同的角度，TDD允许你“重新考虑，没有恐惧”，这是一个关键的好处，你可以出售你的团队。它阻止开发人员对自己说：

• “我不想碰这个代码，因为我怕我会破坏它”
• “我不想在这段代码上编写新功能，因为我不知道它是如何工作的”
• “暗地里，我害怕那个密码”

我可以对更多的内容进行分析，但这是一个很好的基础，比如鲍勃叔叔在TDD和马丁·福勒谈TDD。

Dependencies

哦，我再加一件事。它将向他们展示TDD如何强制进行良好的设计，从而使您能够干净地处理依赖项。

Bob：“噢，c%^p！老板们强迫我们都使用MS SQL Server 2008”Jane：“没关系，因为我们DI数据源和DAO类，所以损失最小，我很高兴TDD鼓励我们走这条路。”

Answer 3

在编写没有自动化测试的源代码时，我们必须非常小心地工作，并且需要更多的评审来保持自信--我们正在进行的更改不会破坏任何现有的功能。

当我们有了良好的自动化测试用例时，结果将是更快、更自信和无畏的开发(它可以是bug修复、增强或重构)。