TDDでモックをどうするのか問題
2021年10月15日
@t_wada テスト駆動開発にはざっくりいうとモックを積極的に使う派（ロンドン学派）とあまり使わない派（デトロイト学派、古典派）がありまして、私は後者なのでほとんど使わず、このエントリに深く同意するところです どちらも素晴らしい本です（ダイレクトマーケティングみたいで申し訳ない）
テスト駆動開発の歴史、デトロイト学派とロンドン学派の分派（?）や重要な発見、バブルとその崩壊、その後のできごと、現代へのつながりなどは『テスト駆動開発』の「付録C」に書いてあります！（ダイレクトマーケティング）
以前 ＃fukabori ep.13 で話したのですが、私がテストで実物とモック（正確にはスタブ）を使い分けるルールははっきりしていて、自分の開発マシンに入るものは常に本物を使い、入らないもの（外部サービスとか）だけモック/スタブを使います（個人の意見です）
Test Double の用語を使うと、ダミーオブジェクトは無害で、フェイクオブジェクトは、色々不変条件を足したりできるので、最初は面倒だけど役に立つことが多い。スタブ、スパイ、モックオブジェクトあたりは逆に簡単にはじめられるけれど最終的には後悔しがちだと思う。
本物の振る舞いと違う&重複が増える
和田卓人さんはあまり使わない。可能な限り本物を使う 「早いスタブ」より「遅くても
クラシックTDDという立場らしい
自分を信頼しない
いつ本物を使うか？
ノートPCにはいるなら本物、そうでないもの(APIとか)はスタブを使うアプローチ
private関数のテスト
public関数のテスト経由でテストできるはず
それでもテストしたいなら責務がある可能性(クラスを抽出できるのでは？)
クリティカルなカバレッジを取りたいというシチュエーションのときは割り切ってリフレクションとか使って書く 実装に基づいているので、リファクタリングに使えるテストにはならない
壊れやすいテスト
書くけど、書きすぎないことが多い
ビューは変わりやすい
ユーザーとの接点で、実験したいことが多い
フレームワークによって書きやすさもまた変わる
見た目レベルのテストをする
スナップショットのテスト
差分が閾値以内か
主要導線のようなコスパが良いテストを書く
単体テストをどこまで書くか
ブラックボックステストやグレーボックスのような仕様レベルのテストが好ましい
カバレッジを達成条件にするとうまく回らない
介入に使うのは悪手
「このくらいテストでカバーできてると思ったらできてなかった」を認識できるツールとして使う
スピードメーター
カバレッジの変化量は管理に使える