ユニットテストの原則

テストは互いに分離して実行されるべき

過度な共通化は避けるべき

• 開発サイクルの中に組み込まれている。積極的に使用するテストからしか価値を得られない。そうでなければ、テストを書く意味がない。
• コードベースの最も重要な部分のみを対象とします(すべてのプロダクションコードに同等の注意が必要なわけではありません。アプリケーションの心臓部（ドメインモデル）を他のものから区別することが重要です。)
• 最小のメンテナンスコストで最大の価値を提供します。この最後の属性を実現するために
  • 価値のあるテスト（ひいては価値の低いテスト）を認識する。
  • 価値あるテストを書く

テストはコードに対してではなく、アプリケーションに対して行うべき

テストとコードの内部構造の間にできる限り距離を置き、代わりに最終結果を検証することを目的とすることです

• モック（Mocks）は、出力される相互作用をエミュレートして検証するのに役立ちます。これらの相互作用は、SUTが依存関係に対し、その状態を変更するために行う呼び出し
• スタブは、入力されるインタラクションをエミュレートするのに役立つ。これらの相互作用は、SUTが入力データを得るために依存関係に対して行う呼び出し

テストを実装の詳細ではなく最終結果 (理想的には、ノンプログラマーにとって意味のあるもの) を検証するようにすること

繰り返し何度も説明されている

状態変更：Mock
参照：Stub

ドメイン層とアプリケーションサービス層の間の懸念事項の分離：ビジネスロジックはアプリケーションの最も重要な部分である。したがって、ドメイン層はそのビジネスロジックにのみ責任を持ち、他のすべての責任から免除されるべきです。外部アプリケーションとの通信やデータベースからのデータ取得などの責任は、アプリケーション・サービスに帰属させなければなりません。逆に、アプリケーション・サービスにはビジネス・ロジックが含まれてはならない。アプリケーション・サービスの責任は、入ってくるリクエストをドメイン・クラスの操作に変換し、その結果を永続化したり、呼び出し元に戻したりして、ドメイン・レイヤーに適応させることです。ドメインレイヤーはアプリケーションのドメイン知識（How-to's）の集合体、アプリケーションサービスレイヤーはビジネスユースケース（What-to's）の集合体として捉えることができます。