我们是否应该从一开始就设计代码以启用单元测试？

目前，我们的团队正在争论是否修改代码设计以允许单元测试是代码的味道，或者在什么程度上可以做到而又没有代码的味道。之所以如此，是因为我们只是刚刚开始实施几乎所有其他软件开发公司中都存在的实践。

具体来说，我们将提供一个非常薄的Web API服务。它的主要职责将是整理Web请求/响应并调用包含业务逻辑的基础API。

一个示例是我们计划创建一个将返回身份验证方法类型的工厂。我们不需要它继承一个接口，因为我们不希望它有任何具体类型。但是，要对Web API服务进行单元测试，我们需要模拟该工厂。

从本质上讲，这意味着我们要么设计Web API控制器类以接受DI（通过其构造函数或设置器），这意味着我们正在设计控制器的一部分，只是为了允许DI并实现我们原本不需要的接口，或者我们使用第三方框架（如Ninject）可以避免以这种方式设计控制器，但是我们仍然必须创建一个接口。

团队中的某些人似乎不愿意仅仅为了测试而设计代码。在我看来，如果您希望进行单元测试，则必须做出一些妥协，但是我不确定他们的担忧如何得到缓解。

需要明确的是，这是一个全新的项目，因此，它并不是真正地修改代码以进行单元测试。这是关于将要编写的代码设计为可单元测试的。

不愿意为了测试而修改代码表明开发人员不了解测试的角色，也不了解他们在组织中的角色。

软件业务围绕提供可创造业务价值的代码库而展开。通过长期的痛苦体验，我们发现，如果不进行测试，就无法创建如此庞大的代码库。因此，测试套件是业务的组成部分。

许多编码人员对这个原则不屑一顾，但是在潜意识里从来没有接受它。很容易理解为什么会这样。认识到我们自己的思维能力不是无限的，实际上，当面对现代代码库的巨大复杂性时，我们的思维能力受到了令人惊讶的限制，这种认识是不受欢迎的，并且很容易被抑制或合理化。测试代码未交付给客户的事实使人们容易相信它是第二类公民，与“基本”业务代码相比不是必需的。而且，将测试代码添加到业务代码中的想法对许多人来说都是双重冒犯。

证明这种做法合理的麻烦在于，通常只有公司层次结构中的高层才能理解软件业务中创造价值的方式的全部情况，但是这些人对以下方面没有详细的技术理解：理解为什么无法摆脱测试所需的编码工作流程。因此，他们经常被从业者安抚，他们向他们保证测试通常是一个好主意，但是 “我们是不需要这样的拐杖的精英程序员”，或者“我们现在没有时间这样的拐杖”，等等。等等。商业上的成功是一个数字游戏，并且避免了技术债务，从而确保了这一事实。质量等仅在长期内显示其价值，这意味着他们通常对此信念非常真诚。

长话短说：使代码可测试是开发过程中必不可少的部分，与其他领域没什么不同（许多微芯片仅出于测试目的而设计了很大比例的元件），但是很容易忽略这样做的充分理由。那。不要陷入陷阱。

这并不像您想的那么简单。让我们分解一下。

• 编写单元测试绝对是一件好事。

但！

• 您对代码进行的任何更改都会引入错误。因此，在没有充分商业理由的情况下更改代码不是一个好主意。

• 您的“非常瘦”的webapi似乎不是单元测试的最佳案例。

• 同时更改代码和测试是一件坏事。

我建议采用以下方法：

1. 编写集成测试。这不需要任何代码更改。它将为您提供基本的测试用例，并使您能够检查所做的任何其他代码更改都不会引入任何错误。

2. 确保新代码是可测试的，并具有单元和集成测试。

3. 确保您的CI链在构建和部署之后运行测试。

设置好这些东西之后，才开始考虑重构旧项目以提高可测试性。

希望每个人都将从过程中吸取教训，并且对最需要测试的地方，如何构造它以及为业务带来的价值有一个很好的了解。

编辑：自从我写了这个答案以来，OP澄清了这个问题，以表明他们在谈论新代码，而不是对现有代码的修改。我也许天真地以为“单元测试好吗？” 争论在几年前就解决了。

很难想象单元测试将需要哪些代码更改，但无论如何都不是您想要的一般良好实践。检查实际的异议可能是明智的，可能是所反对的单元测试风格。

将代码设计为固有可测试的不是代码的味道；相反，这是一个好的设计的标志。基于此的几种著名且广泛使用的设计模式（例如，Model-View-Presenter）提供了简便（容易）的测试，这是一个很大的优势。

因此，如果您需要为具体类编写接口以更轻松地对其进行测试，那是一件好事。如果您已经有了具体的类，则大多数IDE都可以从中提取接口，从而使所需的工作量降至最低。使两者保持同步还需要做更多的工作，但是接口无论如何都不会改变太多，而测试带来的好处可能会超过付出的额外努力。

另一方面，为@MatthieuM。如果在注释中提到，如果您要在代码中添加不应在生产中使用的特定入口点，仅出于测试目的，这可能是一个问题。

恕我直言，很容易理解，对于创建单元测试，要测试的代码必须至少具有某些属性。例如，如果代码不包含可以单独测试的单个单元，则“单元测试”一词甚至没有意义。如果代码不具有这些属性，则必须先对其进行更改，这是显而易见的。

也就是说，从理论上讲，可以尝试先应用所有SOLID原理编写一些可测试的代码单元，然后再尝试对其进行测试，而无需进一步修改原始代码。不幸的是，编写真正可以进行单元测试的代码并不总是那么简单，因此很有可能会有一些必要的更改，只有当尝试创建测试时，这些更改才会被检测到。即使在编写代码时就考虑到单元测试的想法，这也是正确的，对于在开始时就没有将“单元可测试性”放在议程上的代码，绝对是正确的。

有一种众所周知的方法，它试图通过首先编写单元测试来解决该问题-称为测试驱动开发（TDD），它肯定可以帮助从一开始就使代码更可单元测试。

当然，在首先手动测试代码和/或在生产中工作良好的情况下，经常不愿事后更改代码以使其可测试，这是事实。缓解此问题的最佳方法是首先创建一个回归测试套件（通常只需对代码库进行很小的更改即可实现），以及其他附带的措施，例如代码审查或新的手动测试会话。那应该给您足够的信心，以确保重新设计某些内部组件不会破坏任何重要内容。

我对您提出的（未经证实的）断言表示怀疑：

要对Web API服务进行单元测试，我们需要模拟该工厂

不一定是真的。有很多编写测试的方法，并且有很多编写不涉及模拟的单元测试的方法。更重要的是，还有其他种类的测试，例如功能测试或集成测试。很多时候，可以在不是OOP编程语言的“接口”中找到“测试接缝” interface。

一些问题可以帮助您找到替代的测试接缝，这可能更自然：

• 我是否会想在其他 API 上编写瘦Web API？
• 是否可以减少Web API和基础API之间的代码重复？可以根据另一个生成一个吗？
• 我可以将整个Web API和基础API视为一个“黑匣子”单元，并有意义地对整个事物的行为进行断言吗？
• 如果将来必须将Web API替换为新的实现，那么我们将如何做呢？
• 如果将来将Web API替换为新的实现，Web API的客户是否可以注意到？如果是这样，怎么办？

您提出的另一个未经证实的断言是关于DI的：

我们要么设计Web API控制器类以接受DI（通过其构造函数或设置器），这意味着我们正在设计控制器的一部分，只是为了允许DI并实现我们原本不需要的接口，或者我们使用第三方像Ninject这样的框架可以避免必须以这种方式设计控制器，但是我们仍然必须创建一个接口。

依赖注入不一定意味着创建一个新的interface。例如，出于身份验证令牌的原因：您能否简单地以编程方式创建真实的身份验证令牌？然后，测试可以创建此类令牌并将其注入。验证令牌的过程是否取决于某种加密秘密？我希望您没有对密码进行硬编码-我希望您可以以某种方式从存储中读取它，在这种情况下，您可以在测试用例中简单地使用其他（众所周知的）密码。

这并不是说您永远不应该创建一个新的interface。但是不要只局限于一种编写测试的方法，或者一种伪造行为的方法。如果您跳出框框思考，通常可以找到一种解决方案，该方案将代码的扭曲程度降至最低，并且仍然可以为您带来所需的效果。

您很幸运，因为这是一个新项目。我发现测试驱动设计可以很好地编写出色的代码（这就是我们为什么要这样做的原因）。

搞清楚了前面如何调用一段给定的与现实的输入数据的代码，然后让你可以检查是否按照预期，你做的API设计流程早期逼真的输出数据，并得到一个很好的机会有用的设计，因为您不会受到必须重写以适应的现有代码的阻碍。同样，您的同事也更容易理解，因此您可以在此过程的早期再次进行良好的讨论。

请注意，上一句中的“有用”不仅意味着所生成的方法易于调用，而且还意味着您趋向于获得易于在集成测试中建立的干净接口，并为其编写模型。

考虑一下。特别是在同行评审中。以我的经验，时间和精力的投入将很快得到回报。

如果您需要修改代码，那就是代码的味道。

从个人经验来看，如果我的代码难以编写测试，那是不好的代码。这不是不好的代码，因为它不能按设计运行或运行，而是不好的，因为我无法快速了解它为什么起作用。如果我遇到错误，就知道要修复它将是一项艰苦的工作。该代码也很难/无法重用。

好的（干净的）代码将任务分解为较小的部分，这些部分一目了然（或至少看起来不错）很容易理解。测试这些较小的部分很容易。如果我对子节有足够的信心，我还可以编写仅以类似的简便程度测试代码库的部分的测试（重用在这里已经进行了测试，因此也很有帮助）。

从一开始就使代码易于测试，易于重构和易于重用，并且只要需要进行更改，您就不会自杀。

我在完全重建一个本来可以扔掉的原型到更干净的代码中的项目时输入此信息。最好一开始就正确处理并尽快重构错误代码，而不是连续几个小时盯着屏幕，否则会害怕触摸任何东西，以免破坏部分起作用的东西，这要好得多。

我认为编写无法进行单元测试的代码是一种代码味道。通常，如果您的代码无法进行单元测试，那么它就不是模块化的，这将使其难以理解，维护或增强。也许如果代码只是胶粘代码，仅在集成测试方面才有意义，那么您可以用集成测试代替单元测试，但是即使那样，如果集成失败，您也必须隔离问题，而单元测试是一种很好的方法做吧。

你说

我们计划创建一个将返回身份验证方法类型的工厂。我们不需要它继承一个接口，因为我们不希望它有任何具体类型。但是，要对Web API服务进行单元测试，我们需要模拟该工厂。

我并没有真正遵循。拥有工厂创建事物的原因是允许您更改工厂或轻松更改工厂创建的内容，因此不需要更改代码的其他部分。如果您的身份验证方法永远不会改变，那么工厂将是无用的代码膨胀。但是，如果要在测试中使用与生产中不同的身份验证方法，那么让工厂在测试中返回与生产中不同的身份验证方法是一个很好的解决方案。

为此，您不需要DI或Mocks。您只需要工厂支持不同的身份验证类型，并使其可以以某种方式进行配置即可，例如从配置文件或环境变量中进行配置。

在我能想到的所有工程学科中，只有一种方法可以达到体面或更高的质量水平：

在设计中考虑检查/测试。

这在构造，芯片设计，软件开发和制造中都适用。现在，这并不意味着测试是构建所有设计的基础，而不是根本。但是，在做出每个设计决定时，设计人员必须清楚其对测试成本的影响，并就折衷做出明智的决定。

在某些情况下，手动或自动（例如Selenium）测试比单元测试更方便，同时也可以提供可接受的测试范围。在极少数情况下，扔掉几乎未经测试的东西也是可以接受的。但是这些必须根据具体情况有意识地加以决策。调用说明测试“代码气味”的设计表示严重缺乏经验。

我发现单元测试（以及其他类型的自动化测试）倾向于减少代码异味，并且我想不出一个示例来引入代码异味。单元测试通常会迫使您编写更好的代码。如果您不能轻松地使用一种方法进行测试，为什么在您的代码中应该更简单呢？

编写良好的单元测试将向您展示如何使用该代码。它们是可执行文档的一种形式。我看到过丑陋的编写，太长的单元测试，根本无法理解。不要写那些！如果需要编写长时间的测试来设置类，则需要重构类。

单元测试将突出显示您的某些代码气味所在的位置。我建议阅读Michael C. Feathers的《传统代码的有效工作》。即使您的项目是新的，如果它还没有任何（或很多）单元测试，您可能还需要一些非显而易见的技术来使您的代码进行良好的测试。

简而言之：

可测试的代码（通常）是可维护的代码，或者说，难以测试的代码通常很难维护。设计不可测试的代码类似于设计不可修复的机器-可怜的笨拙的人最终将被分配去修复它（可能是您）。

一个示例是我们计划创建一个将返回身份验证方法类型的工厂。我们不需要它继承一个接口，因为我们不希望它有任何具体类型。

您已经知道，三年后您将需要五种不同类型的身份验证方法类型，对吗？需求会发生变化，尽管您应该避免过度设计，但是具有可测试的设计意味着您的设计具有（正好）可以更改的接缝而没有（太多）痛苦-并且模块测试将为您提供自动化的方法来查看您所做的更改不会破坏任何内容。

围绕依赖注入进行设计不是代码的味道，而是最佳实践。使用DI不仅可测试。围绕DI构建组件有助于模块化和可重用性，更轻松地允许替换主要组件（例如数据库接口层）。尽管它增加了一定程度的复杂性，但正确完成后，可以更好地分离层并隔离功能，这使得复杂性更易于管理和导航。这样可以更轻松地正确验证每个组件的行为，减少错误，还可以更轻松地查找错误。

从本质上讲，这意味着我们要么设计Web API控制器类以接受DI（通过其构造函数或设置器），这意味着我们正在设计控制器的一部分，只是为了允许DI并实现我们原本不需要的接口，或者我们使用第三方框架（如Ninject）可以避免以这种方式设计控制器，但是我们仍然必须创建一个接口。

让我们看一下可测试之间的区别：

public class MyController : Controller
{
    private readonly IMyDependency _thing;

    public MyController(IMyDependency thing)
    {
        _thing = thing;
    }
}

和不可测试的控制器：

public class MyController : Controller
{
}

前一个选项实际上有5行额外的代码，其中两行可以由Visual Studio自动生成。一旦设置了依赖项注入框架，以便IMyDependency在运行时替换具体类型（对于任何体面的DI框架，这是另一行代码），所有的Just Works都可以正常工作，除了现在您可以进行模拟并因此测试您的控制器以适应您的内心需求。

6条额外的代码行以实现可测试性……而您的同事认为这“工作量太大”？该论点与我息息相关，也不应与您息息相关。

而且，您不必创建和实现用于测试的接口：例如，Moq允许您模拟具体类型的行为以进行单元测试。当然，如果您不能将这些类型注入正在测试的类中，那么这对您没有多大用处。

依赖注入是您理解它后的其中一件事，您想知道“没有这个我怎么工作？”。这很简单，很有效，而且很有意义。请不要让您的同事缺乏对新事物的理解，以免使您的项目可测试。

当我编写单元测试时，我开始思考代码内部可能出什么问题。它可以帮助我改善代码设计并应用单一职责原则（SRP）。另外，几个月后我再次修改相同的代码时，它可以帮助我确认现有功能没有损坏。

趋势是尽可能多地使用纯函数（无服务器应用程序）。单元测试可以帮助我隔离状态并编写纯函数。

具体来说，我们将提供一个非常薄的Web API服务。它的主要职责将是整理Web请求/响应并调用包含业务逻辑的基础API。

首先为基础API编写单元测试，如果您有足够的开发时间，则还需要为瘦Web API服务编写测试。

TL; DR，单元测试有助于提高代码质量，并有助于将来更改代码而无风险。它还提高了代码的可读性。使用测试而不是评论来表达您的观点。

最重要的是，没有冲突，这是您对勉强的理由的论点。最大的错误似乎是有人提出了“为测试设计”的想法给讨厌测试的人。他们应该只是闭上嘴或用不同的方式说出来，例如“让我们花点时间做正确的事情”。

“必须实现接口”以使某些东西可测试的想法是错误的。接口已经实现，只是尚未在类声明中声明。这是识别现有公共方法，将其签名复制到接口并在类的声明中声明该接口的问题。无需编程，无需更改现有逻辑。

显然，有些人对此有不同的想法。我建议您先尝试解决此问题。