如何对代码进行因素分析以简化可测试性？

Question

我正在学习有关单元测试的知识，并想知道如何编写可测试代码。但是，我不知道如何编写可测试的代码而不使其变得复杂。我将以著名的汽车和发动机问题来描述这个问题。

class Car
{
private:
   Engine m_engine;

public:
   Car();
   // Rest of the car
}

我想出了以下解决方案，使上面的代码可以测试。

1. 将汽车的构造函数更改为以发动机为参数。然后模拟引擎并进行测试。但是，如果我没有不同类型的引擎，那么参数化构造函数只是为了使其可测试是不合适的。
2. 使用setter，然后将模拟引擎传递给setter。和上面的流量相同。
3. 首先测试发动机，然后用经过验证的发动机测试汽车(或使用存根引擎)。

我必须使上面的代码可测试性的替代方案是什么？每种方法的优缺点是什么？

Answer 1

如果你只有一种引擎类型，你为什么要让它成为一个新的对象？如果您不打算交换引擎，就不要创建另一个抽象层。把引擎弄成汽车的一部分。

您可能正在分解以降低复杂性，而不是重用组件。打得好。在这种情况下，我会说3是最好的选择--验证您的低级组件，然后使用调用低级对象的更高级代码。

实际上，引擎更可能是类似于数据库的东西。您可能希望将构造函数更改为使用不同的数据库(出于测试原因或其他原因)，但您可以暂时不使用它。

Answer 2

从不同的角度(测试驱动开发)来看待它:易于测试的代码易于使用。编写单元测试实际上是测试代码的“公共接口”。如果很难测试，那是因为您有一些依赖关系，这使得测试变得很困难。你真的需要一种遏制关系，还是一种关联关系更有意义？

在您的情况下，我个人认为在构造函数中传递引擎会更容易测试，因此我将重构构造函数，如建议1中所示。您可以在一个测试套件中测试引擎，并在另一个测试套件中提供一个模拟引擎来测试汽车。现在测试它很容易，这意味着界面很容易使用。这是一件好事。

现在，考虑一下如何在实际项目中使用该实现。您将创建一个CarFactory类，工厂将创建一个引擎，并在交付给您之前将其放在汽车中。(还请注意，这将如何更紧密地建模汽车、发动机和工厂的真实世界，但我偏离了主题。)

因此，TDD的答案是重构代码，以便在构造函数上获得一个引擎指针。

Answer 3

单元测试，顾名思义，就是对单元进行测试，以确认它们是否按规定工作。这意味着，您应该单独测试引擎。

系统测试或集成测试是测试它们都能正确地结合在一起的测试。

当然，它比这更复杂，但它应该指向正确的方向。