c# - 我是否应该创建域对象的接口(interface)以在单元测试中隔离它们

Question

单元测试和领域对象的接口(interface)在 SO 上都很常见，只是我发现的答案无法将这两个概念结合在一起。

根据本主题Should Domain Entities be exposed as Interfaces or as Plain Objects?

我没有理由为我的项目创建接口(interface)，但目前我在创建测试时遇到困难

我举一个简单的例子:

public MyClass1
{
  public int id {get;set;}
  public MyClass2 Class2{get;set;}
}

如果不创建自己的接口(interface)，然后使用起订量在测试虚拟中创建实现，我如何测试 MyClass1 将其与 MyClass2 隔离？

MyClass1 mc1 = new MyClass1();
IMyClass2 moqC2 = Moq.Get<IMyCLass2>();
mc1.Id = 1
mc1.Class2 = moqC2 

Aseert.That(mc1.Id, Is.EqualTo(1));
Aseert.That(mc1.Class2 , Is.EqualTo(moqC2 ));

如果 MyClass2 有问题，如果 MyClass1 上没有接口(interface)测试可能会失败

编辑

在实际项目中，MyClass1和MyClass2有超过20个属性(具有显式的获取和设置)和一些执行复杂操作的方法。这里我发布一个基本的例子，仅供大家引用

编辑2回复 jgauffin 和 Eben Roux 的好评

有关我的案例的更多详细信息:

根据用户规范，我的主要对象之一是“事件”，每个事件都有许多状态、结果、人员以及每个事件作为社会、类型和分类属性。

但是，即使没有事件，这个对象中的每一个都可以存在，例如，用户想要创建一个包含所有可能状态的状态表，并且这必须在创建单个事件之前完成，对于社会和所有其他引用来说也是如此。

有些只是查找表，并具有广告 ID、说明、开始日期和结束日期以及订单属性。

其他(社会、人员和结果)是具有其他属性和引用的复杂对象(社会有类型、契约(Contract)、员工列表、结构和流程列表；人员有办公室属性、知识列表、晋升历史和等等；该域要复杂得多，有超过 140 个实体，我无法将其全部带回此处，希望这个示例足够了)

因此，所有这些对象都必须在不引用任何事件的情况下创建，但事件可以引用所有对象

我的模型的一小部分

Answer 1

即使它是示例代码，它也不是域实体。这是一个anemic domain model我根本不明白为什么您应该测试它，因为应用程序代码中的任何代码都会使该模型处于不一致的状态。

当您测试域实体时，您应该测试行为。行为是使用实体中的方法添加的。最简单的开始方法是将所有属性 setter 设为私有(private)。

public User
{
  Address _address;

  public User(int id, Address address)
  {
     //assign
  }

  public int Id {get;private set;}

  public bool IsAddressSame(Address address)
  {
      if (address == null)
          throw new ArgumentNullException("address");

      return address.Equals(_address);
  }

  public void Move(Address newAddress)
  {
      if (address == null)
          throw new ArgumentNullException("address");

      var old = _address;
      _address = newAddress;
      DomainEvent.Publish(UserMoved(_old, newAddress);
  }  
}

现在您可以测试地址方法的行为。

how can I test MyClass1 isolating it from MyClass2 if not creating his own interface then using moq to create an implementation in the test dummy?

不要为您的域实体创建接口(interface)。接口(interface)的目的是创建抽象以消除应用程序其他部分的依赖关系。抽象出领域模型有什么意义？在 DDD 中，它是应用程序的核心。没有它，您就没有一个。

由于状态现在受到保护，您知道每个实体都有一个正确的状态。因此，您不需要将用户与地址隔离。相反，只需为您创建的方法编写测试即可。

更新回答评论

"When you test domain entities you should test the behavior" seem good but in TDD i have to write test before and after create implementation, so if i want a Class1 with a Class2 property i first have to test that i have this property

没有。在 TDD 中，您还应该测试行为。依赖关系由行为驱动，反之亦然。

我的意思是，根本没有办法真正知道用户和地址之间存在关系，除非您口头要求应该对用户地址执行某些操作。

根据该要求，您应该在 User 类上测试该方法并且不违反 Law of Demeter直接访问地址即可。