单元测试中有几个神秘的概念，它们就是Mock，模拟对象；Stub，存根；Fake，伪对象，它们听起来很类似，也很容易混淆，让我们通过这篇文章揭开它们神秘的面纱，探索其幽深的小径。

1.什么是伪对象（Fake）

伪对象,通俗的将就是假货！

是用来代替具有“智能”对象的假货实现。通常是一个快捷实现，使它在不同的单元测试中有用，但不能用作集成测试。

到目前为止，我看到的最常见的例子是数据仓储层中。假设我有一个标准的 SQL Server 仓储库，如下所示：

public interface IUserRepository
{void Insert(object user);List<object> GetAllUsers();
}public class UserRepository : IUserRepository
{public List<object> GetAllUsers(){//到数据库取用户集. }public void Insert(object user){//插入用户到数据库}
}

涉及到实际的实现部分时，可能包含逻辑和调用数据库的方法。

当涉及到对可能使用 IUserRepository 的类（例如 UserService）进行单元测试时，我们会遇到一些问题。因为我们不希望我们的单元测试接触到数据库，坦率地说，我们并不真正关心 UserRepository 的实现。

所以我们创建了一个伪对象，而不是直接使用已经实现的真实对象：

public class FakeUserRepository : IUserRepository
{private List<object> _users = new List<object>();public List<object> GetAllUsers(){return _users;}public void Insert(object user){_users.Add(user);}
}

在我们的 fake 中，我们实际上获取了插入的用户，并将其添加到内部列表中。当调用 GetAllUsers 时，我们返回相同的列表。现在，每当单元测试需要调用 IUserRepository 时，我们可以在 FakeUserRepository中进行补充，并且立即“工作”。

这里的主要内容是实现了业务上的相似！

这是一个“真正的”实现，实际上就像一个存储库一样，只是在幕后没有实际的数据库。

2.什么是存根(Stub)

存根是一种返回硬编码响应的实现.

存根没有任何“智能”。没有将对象上的调用捆绑在一起，而是每个方法只返回一个预定义的固定响应。

让我们看看如何为上述创建存根：

public class StubOneUserRepository : IUserRepository
{public List<object> GetAllUsers(){return new List<object>();}public void Insert(object user){//啥都不做~}
}

看起来它有点类似于我们的伪对象，但……不完全是。

这里插入不影响 GetAllUsers，GetAllUsers 本身返回一个没有任何内容的预设响应。我在测试期间对这个对象所做的任何事情都不会改变它的功能。

存根用于满足代码内部的条件，而不是测试功能。

如果我的代码在存储库上调用“插入”，但我并不真正关心我的特定测试的数据会发生什么，那么存根是有意义的，这就省去了编写伪对象“智能”业务的工作。

仓储库的例子显得有些奇葩，因为仓储库总是应该返回动态数据来测试代码中的各种条件。因此，让我使用另一个在现实世界中更有可能需要存根的示例。

假设有一个界面告诉用户是否经过“身份验证”。它看起来像这样：

public interface IUserAuthenticatedCheck
{bool IsUserAuthenticated();
}

现在对于我们的测试，总是需要对用户进行身份验证，也许是为了满足一些基础框架条件。可以像这样定义存根：

public class StubUserAuthenticatedCheckTrue : IUserAuthenticatedCheck
{//返回验证过~~~public bool IsUserAuthenticated() => true;
}

没有是否应该对用户进行身份验证的智能算法，没有其他值，只是一个直接的“总是返回真”的方法。

固定，就是存根擅长的地方。

3.什么是模拟对象(Mock)

模拟是一个预设的对象，可以将动态响应/行为定义为测试的一部分，并预先定义好。

它们不需要去特别实现或实例化，并且（通常）不需要在测试之间共享行为。

我们将在哪里使用 Mock 呢？是您想要相对动态的任何地方，对于特定测试满足条件。

假设我正在编写一个调用以下接口的测试：

public interface IShopService
{bool CheckShopIsOpen(int shopId);
}

我们所做的就是检查商店是开还是关。这个实际实现类可能会调用数据库或某种 webservice/api，但我们不想将其作为单元测试的一部分。

如果在这里使用Fake伪对象，我们需要添加一些虚拟方法来判断商店是应该开还是关。也许是这样的：

public class FakeShopService : IShopService
{public bool ShouldShopBeOpen { get; set; }public bool CheckShopIsOpen(int shopId){return ShouldShopBeOpen;}
}

呃，好像有些复杂，为了能够控制商店是开放还是关闭，我们需要添加新方法。

如果使用存根Stub，必须将真/假响应硬编码到具体类中。可能是这样的：

public class StubShopService : IShopService
{private Dictionary<int, bool> _shops = new Dictionary<int, bool>{{ 1, true },{ 2, false }};public bool CheckShopIsOpen(int shopId){return _shops[shopId];}
}

这适用于预定义的 id 列表，以及商店是开还是关。

但是如果您在测试中使用它并传入 1 的 id，从测试中并不能立即清楚为什么得到 true 的响应，可能需要回来看看你的硬编码？

那么如何使用模拟对象来解决这个问题？（当然建议你直接使用 Moq 库！）：

var _mockShopService = new Mock<IShopService>();
_mockShopService.Setup(x => x.CheckShopIsOpen(1)).Returns(true);

就在测试代码中，当使用模拟对象 ID 为 1 的 CheckShopIsOpen 时，非常清楚，返回 true。

它也是特定于这个测试的，并且不会强迫我们在任何地方硬编码任何东西，或者创建具体的类。

当我们有一个测试要求商店 id 1 为假时…

_mockShopService.Setup(x => x.CheckShopIsOpen(1)).Returns(false);

so easy！

4. 何时使用 Mock、Fake 和 Stub

一切并不是绝对的，你懂得！

• 当想要一个可重用的具体实现时，请使用 Fake，该实现与真实实现类似，具有跨测试的可重用性（例如内存数据库）

• 当想要在测试中重复使用的硬编码响应/实现时使用存根Stub

• 当需要对单个测试进行动态响应时使用 Mock

不过，一般测试可能并不会分的这么严格，大部分情况下，我只使用Mock！不服来战~~~~

好了，希望您能更好地理解这些测试对象的用途，并对何时使用每个对象有更多的了解。

最后，祝你好运！

5.小结

关注我，不迷路！看到这了，点个赞再走！
（思聪语录）别嫌我臭，我就是你的臭宝~~