Highlight
第Ⅲ部の「何をすべきかを表すE2Eを書いて、そのあと最小限の実装を書く」
これ意外とできてないんだよな、最初からレイヤリングしちゃう
フィーチャを足しながらレイヤリング（ポートとアダプタパターン）していく
単一責任の原則に従ってリファクタリングしていく
TDDのサイクル(Red-Green-Refactor)
これにReport(なぜアサーションに失敗したかを読みやすくする)を追加すると今後のメンテナンスのときに役に立つ
Red-Report-Green-Refactor
モックするのは自分が持っている型だけ
自分たち変更できないものをモックしてはならない。
ライブラリをモックしてしまうと、アップデートのたびにふるまいが変わっていないか確認しなければならなくなる。
例えばORMのようなライブラリとやりとりするインターフェイスを作って、そのインターフェイス（アダプタ）をモックする。
実際に永続化できるかは粒度の粗いインテグレーションテストで行う。
インテグレーションテストではアダプタ〜ライブラリをテストする。（ORMであればDBも込みで）
アダプタが何かしらコールバックを受け取る場合はモックして、期待通り呼び出されたことを確認する。
テストのレベル
| 名称 | 対象 | 環境 |
|---|---|---|
| 単体テスト | オブジェクト | 同一プロセス |
| インテグレーションテスト | サードパーティとの結合 | 同一プロセス |
| E2Eテスト | システム全体 | 別プロセス |
インテグレーションテストではシステム全体を持ち出さずに、自分たちのコードとサードパーティのAPIの結合のみに対象を絞る。
E2Eテスト（受け入れテスト）はテスト実行環境とシステム動作環境は別プロセスで切り離された状態で実行する。本番環境に近い環境だと良い。