したがって、標準のアジャイル哲学では、ドメインクラスを単純なPOCOにし、データアクセスオブジェクトを介して別のプロキシレイヤーを使用して永続化することをお勧めします（NHibernateが行うように）。また、可能な限り高い単体テストカバレッジを取得することをお勧めします。
これらの単純なPOCOオブジェクトのテストを作成することは意味がありますか？次のようなクラスがあるとします。
public class Container {
public int ContainerId { get; set;}
public string Name { get; set;}
public IList<Item> Contents { get; set;}
}
これに対してどのような有用な単体テストを書くことができますか？
通常、そのような値オブジェクトは独自のテストを行う必要はありません。実際に何かをするためにそれを使用するクラスからカバレッジを取得します。
単体テストは、動作をテストするように設計されています。行動はありませんか？テストの必要はありません。
実際、クラスを作成する前にこのコードのテストを作成し始めた場合、実装は異なるものになると思います。たとえば、毎回 null をチェックしなくてもコレクションを参照できるように、コレクションを初期化するコンストラクターを作成することになるでしょう。テストが必要ないと思われる場合でも、テストを作成することはおそらく良い習慣だと思います。多くの場合、テストを書いていると、最初のコード試行では対処できなかった多くの仮定が存在することがわかります。
たとえば、ContainerId が 0 未満になることはありますか? 負の値に設定しようとするとエラーになりますか? コレクションをコンストラクターで初期化する必要がありますか、つまり、このコンテナー クラスを使用するクラスは、アクセスする前に null をチェックする必要がありますか?それとも、空である可能性があっても、コレクションが決して null にならないことを保証したいですか?
そうは言っても、私は通常、プロセスにある程度の正気を適用します。たとえば、コンストラクターが内部スコープであり、オブジェクトが Factory クラスによってのみ作成されることがわかっているとします。ファクトリ メソッドをテストして、それらが常に正当なオブジェクトを生成することを確認しますが、必ずしもコンテナー クラス自体をテストする必要はありません。
とにかく、私にとって肝心なのは、クラスにはテストが必要であると想定し、それらを作成しようとし、作成する意味のあるテストが思いつかない場合にのみそれらを省略することです。
これは私の習慣であり、私は決してこれに終止符を打つわけではありませんが、実際に何かを実行する（つまり、デフォルト値を設定する）コンストラクターができるまでテストを作成しません。
言語ではなく、独自のコードをテストする必要があります。新しいContainer（）を作成するたびに、新しいコンテナを取得することが保証されます。そして、あなたがそのステップを台無しにした場合、コンパイラはそれをキャッチしようとしています。
私は単体テストを意図の単位を「呼び出す」ものと考えるのが好きです。
コードで表現されるインテントはゲッターとセッターだけです。言語の一部であるため、それらが機能すると想定しています。
他の意図は表明されていないため、テストは必要ありません。
Contentsただし、プロパティからセッターを削除することをお勧めします。コレクション プロパティは読み取り専用にする必要があります。
これはオブジェクトでさえないと主張したいと思います。オブジェクトはその動作によって定義され、このクラスには何もありません。これは純粋なデータ コンテナーです。それらを持っていても問題ありません-通常はテストは必要ありません-しかし、Anemic Domain Modelにならないように注意してください。テスト駆動開発を使用すると、最初にクラスの動作について考えることが「強制」され、良い練習になるかもしれません。