在“无人问津”的世界中进行单元测试

我不认为自己是DDD专家，但作为解决方案架构师，请尽可能尝试应用最佳实践。我知道围绕DDD中的（公共）二传手“样式”的赞成和反对有很多讨论，我可以看到论点的两面。我的问题是，我在一个拥有各种技能，知识和经验的团队中工作，这意味着我不能相信每个开发人员都会以“正确”的方式做事。例如，如果我们设计域对象以便通过一种方法来执行对对象内部状态的更改，但提供公共属性设置器，则有人将不可避免地设置该属性而不是调用该方法。使用此示例：

public class MyClass
{
    public Boolean IsPublished
    {
        get { return PublishDate != null; }
    }

    public DateTime? PublishDate { get; set; }

    public void Publish()
    {
        if (IsPublished)
            throw new InvalidOperationException("Already published.");

        PublishDate = DateTime.Today;

        Raise(new PublishedEvent());
    }
}

我的解决方案是将属性设置器设为私有，这是可能的，因为我们用来为对象水合的ORM使用反射，因此它能够访问私有设置器。但是，这在尝试编写单元测试时会出现问题。例如，当我想编写一个单元测试来验证我们不能重新发布的要求时，我需要指出该对象已经发布。我当然可以通过两次调用Publish来做到这一点，但是我的测试假设第一次调用正确实现了Publish。好像有点臭。

让我们使用以下代码使场景更真实一些：

public class Document
{
    public Document(String title)
    {
        if (String.IsNullOrWhiteSpace(title))
            throw new ArgumentException("title");

        Title = title;
    }

    public String ApprovedBy { get; private set; }
    public DateTime? ApprovedOn { get; private set; }
    public Boolean IsApproved { get; private set; }
    public Boolean IsPublished { get; private set; }
    public String PublishedBy { get; private set; }
    public DateTime? PublishedOn { get; private set; }
    public String Title { get; private set; }

    public void Approve(String by)
    {
        if (IsApproved)
            throw new InvalidOperationException("Already approved.");

        ApprovedBy = by;
        ApprovedOn = DateTime.Today;
        IsApproved = true;

        Raise(new ApprovedEvent(Title));
    }

    public void Publish(String by)
    {
        if (IsPublished)
            throw new InvalidOperationException("Already published.");

        if (!IsApproved)
            throw new InvalidOperationException("Cannot publish until approved.");

        PublishedBy = by;
        PublishedOn = DateTime.Today;
        IsPublished = true;

        Raise(new PublishedEvent(Title));
    }
}

我想编写验证以下内容的单元测试：

• 除非文件获得批准，否则我无法发布
• 我无法重新发布文档
• 发布时，正确设置了PublishedBy和PublishedOn值
• 发布后，将引发PublishedEvent

如果无法访问设置器，则无法将对象置于执行测试所需的状态。对二传手的开放访问将阻止阻止访问的目的。

您如何解决此问题？

我无法将对象置于执行测试所需的状态。

如果无法将对象置于执行测试所需的状态，则无法在生产代码中将对象置于状态，因此不需要测试该状态。显然，在您的情况下情况并非如此，您可以将对象置于所需状态，只需调用Approve。

• 除非文档已获得批准，否则我无法发布：编写一个测试，要求在批准之前调用publish会导致正确的错误而不更改对象状态。

  void testPublishBeforeApprove() {
      doc = new Document("Doc");
      AssertRaises(doc.publish, ..., NotApprovedException);
  }
  

• 我无法重新发布文档：编写一个批准对象的测试，然后一次成功调用publish，但是第二次在不更改对象状态的情况下导致正确的错误。

  void testRePublish() {
      doc = new Document("Doc");
      doc.approve();
      doc.publish();
      AssertRaises(doc.publish, ..., RepublishException);
  }
  

• 发布后，正确设置了PublishedBy和PublishedOn值：编写一个调用批准然后调用publish的测试，断言对象状态正确更改

  void testPublish() {
      doc = new Document("Doc");
      doc.approve();
      doc.publish();
      Assert(doc.PublishedBy, ...);
      ...
  }
  

• 发布后，将引发PublishedEvent：挂接到事件系统并设置一个标志以确保它被调用

您还需要编写批准测试。

换句话说，不要测试内部字段与IsPublished和IsApproved之间的关系，如果这样做，则测试将非常脆弱，因为更改字段将意味着更改测试代码，因此该测试将毫无意义。相反，您应该以这种方式测试公共方法的调用之间的关系，即使您修改了字段也不需要修改测试。

另一种方法是创建类的构造函数，该构造函数允许在实例化时设置内部属性：

 public Document(
  String approvedBy,
  DateTime? approvedOn,
  Boolean isApproved,
  Boolean isPublished,
  String publishedBy,
  DateTime? publishedOn,
  String title)
{
  ApprovedBy = approvedBy;
  ApprovedOn = approvedOn;
  IsApproved = isApproved;
  IsApproved = isApproved;
  PublishedBy = publishedBy;
  PublishedOn = publishedOn;
}

一种策略是您继承该类（在本例中为Document）并针对继承的类编写测试。继承的类允许通过某种方式设置测试中的对象状态。

在C＃中，一种策略可能是将设置器内部化，然后将内部结构暴露给测试项目。

您也可以像描述的那样使用类API（“我当然可以通过两次调用Publish来做到这一点”）。这将使用对象的公共服务来设置对象状态，对我来说似乎并不难。就您的示例而言，这可能就是我要做的方法。

为了绝对隔离地测试域对象接收到的命令和查询，我习惯为每个测试提供对象处于预期状态的序列化。在测试的“安排”部分，它从我之前准备的文件中加载要测试的对象。起初，我从二进制序列化开始，但是事实证明，json易于维护。每当测试中的绝对隔离提供实际价值时，这证明行之有效。

仅编辑一个注释，有时JSON序列化会失败（就像循环对象的图一样，这是一种气味，顺便说一句）。在这种情况下，我可以进行二进制序列化。这有点实用，但是可以。:-)

你说

尽可能尝试应用最佳做法

和

我们用来水合对象的ORM使用反射，因此它能够访问私有设置器

而且我不得不认为，使用反射绕过类的访问控制并不是我所描述的“最佳实践”。它也将非常缓慢。

就个人而言，我会废弃您的单元测试框架，并在类中添加一些内容-看来您是从测试整个类的角度编写测试，这很好。过去，对于一些需要测试的棘手组件，我将断言和设置代码嵌入到类本身中（以前是在每个类中都有一个test（）方法的常见设计模式），因此您创建了一个客户端它只是实例化一个对象并调用测试方法，该方法可以根据需要进行设置，而不会像反射hack那样令人讨厌。

如果您担心代码膨胀，只需将测试方法包装在#ifdefs中，以使其仅在调试代码中可用（可能是最佳实践本身）