単体テストの使い方/第5章まとめ

テスト・ダブルとは

テストの際に使われるプロダクションコードには含まれない偽りの依存として表現される全てのものを包括的に意味するものである。

テスト・ダブルには以下の種類がある

1. ダミー

2. スタブ

3. スパイ

4. モック

5. フェイク

これらのスタブを2分割することができる

• スタブ - ダミー、スタブ、フェイク

• モック - モック、スパイ

モックは外部に向かうコミュニケーション(出力)を模倣する場合と検証する場合に使われる。
ここでいう外部に向かうコミュニケーションとはテスト対象システムが依存に対してその依存の状態を変えるために行う呼び出しである。
スタブは内部に向かうコミュニケーションとは、テスト対象システムが依存からデータを取得するために行う呼び出しである。

スタブとのやり取りを検証することは、
テストを壊れやすくすることに繋がる
【理由】
スタブとのやりとりは最終的な結果の一部となるものではなく、その最終的な結果を生み出す過程の中で使われるのもに過ぎない。
つまり、スタブとのやり取りは実装の詳細ということになる。

コマンド・クエリ分離の原則

コマンド・クエリ分離の原則 --- 全てのメソッドはコマンドかクエリかのどちらかになるべきであり、両方の性質を持つべきではないということを提唱している。
そして、コマンドクエリをテスト・ダブルに置き換える場合、コマンドの代わりとなるものがモックであり、クエリの代わりとなるのがスタブである。

全てのプロダクションコードは

• 公開されたAPI or プライベートなAPI

• 観察可能な振る舞い or 実装の詳細

以上の二つの観点で分類できる。

コードをどのくらい後悔するのかはprivateやpublicやinternalなどのアクセス修飾子をつけることで制御できる。

きちんと設計されたコードとは
-> 観察可能な振る舞いが公開されたAPIと一致しており、実装の詳細がプライベートなAPIとして隠されるコードのこと

もし公開されたAPIに観察可能な振る舞いではないものが含まれてしまうと、そこから実装の詳細が漏洩することとなる。

そういった情報の漏洩する危険性などを防ぐためには「カプセル化」が必要となる。

カプセル化

カプセル化 -> 不変条件の侵害からコードを守るための手段のことである。

実装の詳細が漏洩してしまうと、外部から不変条件を無視して実装の詳細を操作できるようになってしまい、カプセル化に繋がる。

ヘキサゴナル・アーキテクチャ

ヘキサゴナル・アーキテクチャ -> 六角形で表現されたアプリケーション同士を組み合わせていくことおで構成されるアーキテクチャのこと。

このアーキテクチャの各アプリケーションをドメイン層とアプリケーション・サービス層の2層で構成される。

ヘキサゴナル・アーキテクチャには三つの重要な性質がある

• ドメイン層とアプリケーション・サービス層との関心が分離されている。ドメイン層の関心はビジネス・ロジックであり、アプリケーション・サービス層の関心はドメイン層と外部アプリケーションとの連携を指揮することである。

• アプリケーション・サービス層とドメイン層の依存関係はアプリケーション・サービス層からドメイン層への一方向になっている。そのため、ドメイン層のクラスは同じドメイン層の別のクラスに依存しても構わないが、アプリケーション・サービス層のクラスには依存してはならない。

• 外部アプリケーションがテスト対象アプリケーションのドメイン層に何らかの操作を行う場合、アプリケーション・サービス層によって管理されている共通のインターフェイスを必ず経由させるようになってきている。そうすることで、外部アプリケーションがドメイン層に直接アクセスできないようにしている