「セッターなし」の世界での単体テスト

私は自分自身を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がリフレクションを使用してプライベートセッターにアクセスできるためです。ただし、単体テストを作成しようとすると問題が発生します。たとえば、再発行できないという要件を検証する単体テストを作成する場合、オブジェクトが既に発行されていることを示す必要があります。確かに2回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が発生します

セッターへのアクセスなしでは、オブジェクトをテストの実行に必要な状態にすることはできません。セッターへのアクセスを開くと、アクセスを防止する目的が無効になります。

この問題をどのように解決しますか？

オブジェクトをテストの実行に必要な状態にすることはできません。

オブジェクトをテストの実行に必要な状態にできない場合、オブジェクトを製品コードの状態にできないため、その状態をテストする必要はありません。明らかに、これはあなたの場合には当てはまりません。オブジェクトを必要な状態にすることができ、承認を呼び出すだけです。

• ドキュメントが承認されない限り公開できません。承認を呼び出す前に発行を呼び出すと、オブジェクトの状態を変更せずに正しいエラーが発生するというテストを記述します。

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

• ドキュメントを再発行することはできません。オブジェクトを承認するテストを記述し、成功するとパブリッシュを呼び出しますが、2回目にはオブジェクトの状態を変更せずに正しいエラーが発生します。

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

• 発行されると、PublishedByおよびPublishedOnの値が適切に設定されます。承認を呼び出してから発行を呼び出すテストを作成し、オブジェクトの状態が正しく変更されることをアサートします

  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;
}

1つの戦略は、クラス（この場合はDocument）を継承し、継承されたクラスに対してテストを作成することです。継承されたクラスにより、テストでオブジェクトの状態を設定する何らかの方法が可能になります。

C＃での1つの戦略は、セッターを内部にし、内部をテストプロジェクトに公開することです。

説明したようにクラスAPIを使用することもできます（「Publishを2回呼び出すことでこれを実行できます」）。これは、オブジェクトのパブリックサービスを使用してオブジェクトの状態を設定することになるため、私にはあまり臭いがしません。あなたの例の場合、これはおそらく私がやる方法でしょう。

ドメインオブジェクトが受け取るコマンドとクエリを完全に分離してテストするために、各テストに期待される状態のオブジェクトのシリアル化を提供するために使用されます。テストのarrangeセクションでは、事前に準備したファイルからテストするオブジェクトをロードします。最初はバイナリシリアル化から始めましたが、jsonの方がずっと簡単に管理できることがわかっています。これは、テストでの絶対的な分離が実際の価値を提供するときはいつでも、うまく機能することが証明されました。

メモを編集するだけで、JSONのシリアル化が失敗する場合があります（循環オブジェクトのグラフの場合、臭いがするなど）。このような状況では、バイナリシリアル化を利用します。少し実用的ですが、動作します。:-)

あなたは言う

可能な限りベストプラクティスを適用するようにしてください

そして

オブジェクトをハイドレートするために使用しているORMはリフレクションを使用するため、プライベートセッターにアクセスできます。

また、リフレクションを使用してクラスのアクセス制御をバイパスすることは、「ベストプラクティス」とは言いません。その速度も恐ろしく遅くなります。

個人的には、ユニットテストフレームワークを破棄し、クラス内の何かに取り組みます。とにかくクラス全体をテストするという観点からテストを書いているようです。過去には、テストが必要ないくつかのトリッキーなコンポーネントについては、アサートとセットアップコードをクラス自体に埋め込みました（これは、すべてのクラスにtest（）メソッドを持つ一般的なデザインパターンでした）ので、クライアントを作成しますこれは単にオブジェクトをインスタンス化し、リフレクションハックのような厄介なことなく自分で好きなようにセットアップできるテストメソッドを呼び出します。

コードが肥大化している場合は、テストコードを#ifdefsでラップして、デバッグコードでのみ使用できるようにします（おそらくベストプラクティス自体）