# 第9章

## モックよりもスパイ: p316

ここでいう「スパイ」は広く知られているスパイとはことなるかも？ここでは「手書きのモック」のこと

## プロダクション・コードを信頼すべきではない: p318

この例では、発せられるメッセージ自体を検証しようとしているため、「メッセージ自体が変わるとテストは失敗するようにな」るのが想定されて挙動のように見える（つまりスパイが正しく機能している）。
モックではメソッドの呼び出しの確認にとどまるため、テストとして不十分（プロダクション・コードを信頼しすぎている）という主張と理解した。

## モックの対象になる型は自身のプロジェクトが所有する型のみにする: p322

- ライブラリのラッパーアダプタをモックする = プロジェクトが所有する型
  - ライブラリのラッパーは薄皮一枚でほとんど意味がないのでは？
  - ライブラリを使う意味がなくなるのでは？

### IMessageBus（p312）、IBus（p316）について

- IMessageBusはどのようなメッセージを送るかをドメイン特有の用語をつかって規定している（SendEmailChangedMessage）
- IBusはライブラリ利用に関する複雑さ（接続時のクレデンシャルの使用、必須リクエストヘッダーの追加など）を隠すライブラリラッパーインターフェース

このとき、アプリケーションの境界に位置するのはIBusなのでIBusをモックする（p313図9.1）

## モックは統合テストに限定する: p320

バリバリの古典/デトロイト学派としての意見。管理外の依存のみモックするという主張からは当然の意見でもある。

> モックを使うのはコントローラを検証するとき、つまり、統合テストを行うときだけとなる。言い換えると、単体テストでは、モックを使ってはならない。
> -- p324

> モックはアプリケーションの境界に限りなく近い部分のみにする
> -- p311-

> モックの呼び出し回数を常に確認する
> -- p321
>
> 想定している呼び出しが行われていること、および、想定していない呼び出しが行われていないこと の両方を確認しなくてはならない。
> -- p325

「呼び出し回数を確認するテストをやらない」派だが、この本のベストプラクティスから外れていた（むしろアンチパターン）