ドメインオブジェクトの作成をテストする単体テスト

次のような単体テストがあります。

[Test]
public void Should_create_person()
{
     Assert.DoesNotThrow(() => new Person(Guid.NewGuid(), new DateTime(1972, 01, 01));
}

ここでPersonオブジェクトが作成された、つまり検証が失敗しないと断言しています。たとえば、Guidがnullの場合、または生年月日が1900年1月1日より前の場合、検証は失敗し、例外がスローされます（テストが失敗したことを意味します）。

コンストラクターは次のようになります。

public Person(Id id, DateTime dateOfBirth) :
        base(id)
    {
        if (dateOfBirth == null)
            throw new ArgumentNullException("Date of Birth");
        elseif (dateOfBith < new DateTime(1900,01,01)
            throw new ArgumentException("Date of Birth");
        DateOfBirth = dateOfBirth;
    }

これはテストのための良いアイデアですか？

注：ドメインモデルの単体テストに古典的なアプローチを採用している場合は、それが何らかの意味を持っています。

これは有効なテストです（かなり熱心ですが）。私は時々コンストラクターロジックをテストするためにそれを行いますが、Laivがコメントで述べたように、理由を自問する必要があります。

コンストラクタが次のようになっている場合：

public Person(Guid guid, DateTime dob)
{
  this.Guid = guid;
  this.Dob = dob;
}

それがスローされるかどうかをテストすることには多くのポイントがありますか？パラメータが正しく割り当てられているかどうかは理解できますが、テストはかなりやり過ぎです。

ただし、テストで次のようなことが行われる場合：

public Person(Guid guid, DateTime dob)
{
  if(guid == default(Guid)) throw new ArgumentException("Guid is invalid");
  if(dob == default(DateTime)) throw new ArgumentException("Dob is invalid");

  this.Guid = guid;
  this.Dob = dob;
}

その後、テストの関連性が高まります（実際にコードのどこかに例外をスローしているため）。

一般的に言って、コンストラクタに多くのロジックを含めることは悪い習慣です。基本的な検証（上記のnull / defaultチェックなど）は大丈夫です。しかし、データベースに接続して誰かのデータをロードしている場合、そこからコードの臭いがし始めます...

このため、コンストラクターをテストする価値がある場合（多くのロジックがあるため）、他の何かが間違っている可能性があります。

ビジネスロジックレイヤーでこのクラスをカバーする他のテストがほぼ確実に行われます。コンストラクターと変数の割り当ては、ほぼ確実にこれらのテストから完全にカバーされます。したがって、コンストラクタ専用の特定のテストを追加することは無意味かもしれません。しかし、何も白黒ではなく、コードレビューを行っていればこれらのテストに対して何もしませんでしたが、ソリューションの他の場所のテスト以上に価値を追加するかどうかは疑問です。

あなたの例では：

public Person(Id id, DateTime dateOfBirth) :
        base(id)
    {
        if (dateOfBirth == null)
            throw new ArgumentNullException("Date of Birth");
        elseif (dateOfBith < new DateTime(1900,01,01)
            throw new ArgumentException("Date of Birth");
        DateOfBirth = dateOfBirth;
    }

検証を行うだけでなく、ベースコンストラクターも呼び出します。コンストラクター/検証ロジックが2つのクラスに分割され、可視性が低下し、予期しない変更のリスクが高まるため、これらのテストを行うより多くの理由があります。

TLDR

これらのテストにはいくつかの価値がありますが、検証/割り当てロジックはソリューションの他のテストでカバーされる可能性があります。重要なテストを必要とするこれらのコンストラクターに多くのロジックがある場合、そこに潜んでいる厄介なコードの匂いがあることを示唆しています。

ここではすでに良い答えですが、もう1つ言及する価値があると思います。

「本で」TDDを行う場合、コンストラクターが実装される前であっても、コンストラクターを呼び出すテストを最初に記述する必要があります。そのテストは、コンストラクターの実装内に検証ロジックがない場合でも、実際に提示したテストのように見える可能性があります。

また、TDDの場合、次のように最初に別のテストを記述する必要があります。

  Assert.Throws<ArgumentException>(() => new Person(Guid.NewGuid(), 
        new DateTime(1572, 01, 01));

DateTime(1900,01,01)コンストラクタにチェックを追加する前に。

TDDのコンテキストでは、示されているテストは完全に理にかなっています。