问如何在测试类中验证方法类

EN

在存储库中使用ConvertToBusinessEntity并不是很好的主意。存储库的职责是使用数据存储(CRUD)。数据类型的映射是某些映射类的责任。否则，存储库有太多的责任。看看你要测试的是什么：

我检查数据是否从数据源和中正确检索，这些值被放入实体正确的属性中。

你看到这个了吗？你的考试可能会因为两个完全不同的原因而失败。另外，您应该根据两个完全不同的原因更改存储库。这里的最佳方法是直接持久化业务实体。现代ORMs允许这样做，而不会污染具有属性的业务实体，或者强制它继承某些特定的数据访问类。

如果您真的希望存储库中有数据映射逻辑，那么将其设置为私有(实际上，只有存储库应该要求将业务实体转换为某些数据访问对象)，并且不关心如何实现该逻辑。让它成为内部类实现的一部分。您应该只关心存储库能够接受或返回已填充的业务实体--这是存储库的责任。在存储库中如何实现映射并不重要。您应该测试存储库是做什么的，而不是如何。因此，只需检查存储库是否返回了预期的业务对象。

我只需要知道如何验证被测试类中的方法是否被调用(而不是依赖项)。

但是，你真的需要这样做吗？如果您的GetEntity方法操作正确，您真的关心它是如何操作的吗？您真的关心它是通过委托给ConvertToBusiness还是通过其他方式来执行其功能的呢？

我建议你

1. 把每一种方法都看作是有一个规范。
2. 该规范描述了它必须进行的输出和公开可见的操作。这并不描述方法是如何执行其功能的；这是一个可能发生变化的实现细节。
3. 单元测试只检查您的方法是否符合它们的规范。
4. 不过，您可以使用有关实现的知识来选择好的测试用例。

但是，您可以声明，如果我这样做，我不是单元测试我的方法代码；我对GetEntity的测试依赖于GetEntity方法和ConvertToBusiness方法:两个单元，所以是一个集成测试，而不是一个单元测试。但是，您会嘲笑运行时环境的方法吗？当然不是。单元测试和集成测试之间的界限不是很清楚。

从哲学上讲，在许多情况下，您无法创建良好的模拟对象。原因是，对于大多数方法，对象委托关联对象的方式是未定义的。它是否委托以及如何委托是由规范作为实现细节留下的。唯一的要求是，在委托时，该方法满足其委托的先决条件。在这种情况下，只有完全功能(非模拟)的委托才能完成任务。如果真正的对象检查它的先决条件，如果不能满足委托的先决条件，就会导致测试失败。并且调试这个测试失败将是容易的。