実装の詳細

観測可能な振る舞いをテストすることが大事

誰がクライアントか？

そしてそのクライアントが達成したいことはなんなのかで変わる

主に二つの条件のどちらかを満たしているもの

クライアントの目標の一つにメソッドが結びついてる

アプリケーションから確認できる副作用がプロセス外依存で起こる

本だと外部のクライアントからリクエストがあってメール送信されるとかが例で挙げられてる

だから協力者オブジェクトみたいな観測可能な振る舞いと違う箇所をテストするときにモックで置き換えるべきでは無い。

そこは観測可能な振る舞いをテストしてたら意識てなくても知らなくてもいい場所だから

正直なところ線引きがわからん。

視点が変われば何が実装の詳細かは変わるから、全て実装の詳細でありそうでは無いみたいな感じなのかも。

視点が高い位置からみたら実装の詳細であっても視点を変えたら実装の詳細が観測可能な振る舞いに変わる

つまり高いそうで実装の詳細を一つもテストしないって意味ではなくて視点によって何が実装の詳細かは変わるのでその視点でのテストは可能になる。

外部のクライアントの場合もあるし、コントローラーをクライアントとする場合もある。要はその処理の中で何を達成したいのか。

コントローラーからしてみてUserクラスのメソッドを呼び出すときに中で他のクラスを呼び出してるとかは知らなくていいことだしそれをコントロールのテストで書くべきでは無い。

って考えるとそんなに難しく無いかもね。

複数達成したいことがある場合とかだと責務が複数あるということなのかな？

常に一つのことをすべきってなるならそうなのかもね。

参考

コードに問題があるがテストにpassしているが偽陽性、コードに問題ないがテストがエラーになってるが偽陰性って感じで逆に書かれてるのでちょっとややこしい。テストがpassすること自体をpositiveに当ててるけど他の記事とかだと通ることをnegativeとして紹介していてたりする。

偽陽性とは、プロダクトコードが正しいにもかかわらずテストが失敗してしまう状況です。偽陰性とは、プロダクトコードが誤っているにもかかわらずテストが成功してしまう状況です。これらは火災報知器をイメージするとわかりやすいでしょう。火が出ていないのに、火災報知器が鳴るなら誤検知（偽陽性）です。火が出ているのに、火災報知器が鳴らないなら検知漏れ（偽陰性）です。

正直どっちでもいいけど、問題ないのに検査薬で陽性でしたってのが偽陽性の方がなんかしっくりくるから、プロダクトコードは問題ないのにテスト（検査）がエラーになるのが偽陽性って方がしっくりくる感じがする。