古典学派とロンドン学派の違い
2.の「単体」の定義も微妙に異なる
著者は古典学派を支持しており、ロンドン学派の利点を叩き台に古典学派の立場から反論していく
ロンドン学派のメリット1) 1つのテストケースで1つのクラスしか検証しないため粒度が細かい
ロンドン学派では「単体」を一つのクラスとして捉えている
これはOOPに由来する考え方だが、別に正当性があるわけではなく、むしろOOPの技術的な制約に過ぎない
問題領域において意味があるもの＝ユーザにとって有用なものを検証するようにする
意味のあるまとまりでないと何をテストケースで検証したいのか曖昧になってしまうため、これが質の悪さにつながる
理想的なテストケースはテスト対象のコードが解決しようとしている物語が伝わってくる
テストケースがテスト対象の意味を書き起こしたドキュメントのように読める
非開発者でも理解できるレベルの物語がベストで、そこまで上げるためには凝集度を高める必要がある
凝集度の高い物語
私が犬の名前を呼ぶと、その犬は私のところに寄ってきます。
凝集度の低い物語
私が犬の名前を呼ぶと、その犬は左前足を動かし、次に右前足を動かし、頭を私の方に向け、しっぽを振り始め……（略）
このレベルで細かい検証をするのはコスパが悪いし、何がしたいのかテストケースから読み取りづらい
avashe.iconユースケースを細分化したような単位で検証すべきというのはわかりやすいが、これはこれで振る舞いの単位の定義問題になりそうな気もする
問題設定が間違っており、まず複雑な依存関係を作りこんでいる設計が問題だ
古典学派の立場としては、むしろ複雑な依存関係になってしまうような間違った設計を検出したと言える
もしAAAパターンの準備フェーズが大きくなるようであれば設計上の問題がある可能性が高い ロンドン学派のメリット3) テストが失敗した場合どの機能に問題があったのか正確に見つけられる
古典学派であってもCIで頻繁に実施していれば最後に修正した箇所にテストを失敗させた原因があることになるため、バグの発生個所がすぐわかる
avashe.iconちょっと擁護的だけど、実運用上そこまで困らんよね？というのはそう
逆に言うと、ロンドン学派を採用するとプロセス外依存の変動によって困らされることがなくなるので、依存の仕様変更が解決するまでしばらくCIが動きませんが回避してくださーい！というやりとりがなくなるよね
1つのコード上の問題が多くのテストケースに影響するなら、その問題のコードは多くのクラスに依存されるような価値あるコードであることの証明になる
avashe.icon興味深い依存のパスがあったら公開の場所にメモっておくといいかも
その他の違い
ロンドン学派は外側から内側へ向かうテスト駆動開発
テスト対象システムがどの協力者オブジェクトとコミュニケーションを取るか、モックを使って明確に実装していく
古典学派は内側から外側へ向かうテスト駆動開発
ドメインモデルから実装とテストを始めていき、徐々に外の層の実装へ移っていく
テストコードが把握することになるプロダクションコードの詳細
一般的にロンドン学派の方が古典学派よりも実装の詳細に深く結びつく傾向にあり、著者が古典学派支持なのもそれが大きいという。詳細は後述。
avashe.icon本書やバイブルとなる本を読まないと、まだ結論出せないな
ロンドン学派では、実際の協力者オブジェクトを使って行うテストをすべて統合テストと見なす
古典学派のほとんどの単体テストが統合テスト扱いになる
E2Eテストはよりプロセス外依存の多い統合テストと見なせる
統合テストは自動で準備するのが容易なプロセス外依存を1,2個含むイメージ
E2Eテストは他にUIテスト、GUIテスト、機能テストとも呼ばれるが同じ