模拟.nettiers DataRepository调用

Question

我有一个项目，其中我使用.nettiers生成的代码作为我的DAL。

目前，我的测试包括在数据库中为每个测试物理设置测试数据，然后允许nettiers对象访问数据库并根据需要返回。

显然，这并不是特别有效，到目前为止，我的250多个测试大约需要10分钟才能运行，所以我一直在考虑在我的测试中添加mocking。

虽然我非常确定我理解模拟数据库调用的概念，但我在将其应用于网络层时遇到了问题，因为它与数据库的耦合性相当强。

我想要测试的方法之一是这样的(为了简洁起见，稍微删减一下)：

public class InterfaceManagerService
{
    public DataDocument SaveDataDocument(DataDocument entity)
    {
        var lookupEntity = DataRepository.DataDocumentProvider.GetByDocumentId(entity.DocumentId);
        if (lookupEntity == null)
        {
            File fileEntity = new File();
            fileEntity.Name = entity.Name;

            var savedFileEntity = DataRepository.FileProvider.Save(fileEntity);

            entity.FileId = savedFileEntity.FileId;

            var savedEntity = DataRepository.DataDocumentProvider.Save(entity);

            return (savedEntity);
        }             
    }
}

目前，我正在使用Typemock的试用版本，因为它似乎可以做所需的事情，但我对任何替代方案都持开放态度，特别是开源的。

我遇到的第一个问题是，我是否应该创建InterfaceManagerService的模拟实例，或者DataRepository的模拟实例，或者实体本身(nettiers实体确实有一个可能有用的接口)。

第二个问题是，如何创建要返回的伪对象，因为nettiers将一堆额外的属性放入实体中，如果我为我期望的每个对象创建一个伪实例，则会导致大型且笨拙的测试。

我猜最终，我正在寻找一些方向，为使用nettiers数据存储库方法的方法编写单元测试，但避免访问数据库，因为目前在互联网上似乎没有太多关于它的内容。

Answer 1

我将从我的个人经验中给出一些建议。虽然这些可能不能解决您所关心的所有问题，但我希望它们至少能对您有所帮助。

• Rhino Mock是一个相当知名的模拟框架。如果你正在寻找Typemock的替代品，我会建议你是模拟InterfaceManagerService还是DataRepository，我会说这取决于你要测试的是什么。是否要测试InterfaceManagerService？然后，您可能希望为DataRepository.FileProvider和DataRepository.DataDocumentProvider创建模拟对象。如果您还不熟悉“依赖注入”的概念，那么可以研究一下；看起来您应该对您的InterfaceManagerService类应用一些依赖注入(假设您想要对它进行单元测试)。

如果您想对使用InterfaceManagerService的代码进行单元测试，那么只需模拟InterfaceManagerService.

...如何创建要返回的伪对象，因为nettiers将一堆额外的属性放入实体中，如果我为我期望的每个对象创建一个伪实例，将会导致大而笨拙的测试。

• 编写单个单元测试很容易。编写许多单元测试以涵盖您需要涵盖的所有场景，并以一种有效的方式执行此操作，并且不会导致在整个单元测试中重复太多代码，这是很困难的，尤其是当被测试方法的输入和输出非常复杂时。

对于这一点，我没有太多的指导，除了说我个人的方法是尝试合并测试初始化逻辑和测试验证逻辑，以避免大量代码重复，但同时我试图避免使单元测试代码本身变得过于复杂，使其变得难以理解并容易出现错误。

总的来说，我认为我最终将测试逻辑分为3类:输入/初始化、期望和结果/验证。我发现将逻辑放在这3个类别中对我能够跨单元测试合并公共代码很有帮助。

顽固的测试驱动开发的支持者可能会说，努力生成一组干净的单元测试代码是应用程序中存在设计缺陷的迹象。我不会反对这一点，但我要说的是，不幸的是，我所参与的项目通常没有生成既简单又全面的单元测试代码库。简单的单元测试通常并不真正探索有问题的场景，而全面的单元测试通常需要大量的测试设置逻辑。

Answer 2

我使用TypeMock，我非常喜欢它。模拟类的内部结构真的很容易。我希望做的是覆盖DataRepository类，并让TypeMock向使用它的组件返回一个预期的结果集，以确保该组件按预期工作。

但实际上，这取决于您正在测试的是什么。如果您正在测试服务，请伪造数据存储库并返回预期结果。如果您正在测试存储库，则伪造存储库消耗的内部结构。所以一个好主意是伪造你正在测试的组件的外部引用，IMHO。

HTH。