概要

単体テストの考え方/使い方をほぼ読み終わったので、本全体の所感や学びになったポイントをかい摘んで書き残してみたい。

所感

▼この本はつまり

「単体テスト」を中心に、質の良いテストとは何か、質の悪いテストとは何か、どのような方法で実現すべきなのかをコード改修を通して学べる本。
テスト駆動であろうがなかろうが、テストコードを書く人には漏れなくお勧めできる本と感じた。

テスト駆動とは何ぞやとか、その方法はとか、テストファーストがどうのとか、「テスト」を取り巻く変遷、などには触れていない。
（ただし「単体テスト」の捉え方の流派として「古典学派」と「ロンドン学派」の違いなどには触れている）

▼前提

筆者のテスト歴はプロダクションコードを書く際にテストコードを普通に書く環境になって1年程度。言語はgolang。テスト駆動開発本を読んで、可能ならテスト駆動でコーディングしている（つもり）。

▼この本の何が良かったか

テストコードを書いている中で色々なモヤモヤがあった。

• モックは使うべきなの？使わないべきなの？

• どこでモックを使うの？

• モックとかスタブとか言うけど何が正解？

• 単体テストっていう割にごちゃごちゃしたテストコードだけどこれって単体テスト？

• テストコードも効率良く共有コード書きたい

• 何だかテスト書くのは正しいことしている謎の貢献感を感じちゃってるけど、こんな工数掛かっていいの？

• リファクタしたらテストぶっ壊れるけど・・こういうもの？

• テストをパス出来るようにテストコード修正したけど、こんな工数掛かっていいの？

この本はこれらに答えてくれるだけではなく、なぜそうあるべきかが分かる。そして体系的に理論を学べるため、応用して自分で価値基準を持って判断出来るようになる。
逆引き辞書のような答えが手に入ることではなく、答えを手に入れる道具（知識）を手に入れられる。

▼モヤモヤ=理解していないし、上手くいっていない臭い

まず1つ取り上げると、「モック」という存在1つ取ってもモヤモヤし続けていた。何でモックを使うのかが分からなかった。モックとは何ぞや、何のためにあるのか、どう使うべきか、など理解しておらず、そのせいで一応悪い臭いは嗅ぎ分けるが、蓋をするだけだった。

「DBに依存して（必要になって）しまうから」は、本当にプロジェクト最初の何も無い状態でプロトタイプを作成する時に急ごしらえで一部実装をでっち上げるような時には必要かもしれないが、それ以外はDBを操作しないで検証するのはメリットが薄いんじゃないかと思う。

「外部サービス使うから」はそれはその通りモックにしないと外部影響出てしまうので理解出来る。

「モックじゃないと大変（工数膨らむ、再現出来ない）」は理解出来そうだが、その状況そのものが改善が必要と直感的に感じる。手数的に簡易に出来るようにする、複雑さを分解、抽出して単純の組み合わせで出来るようにする、などきっと改善出来るはず。

「モックにすれば入出力も、期待したメソッドを期待した数だけ通ったか細かく検証出来るから」は最初はなるほどそういうものか、きっちり検証出来ていいものだなと思った。ただしテスト対象の処理の道中で引き回す引数が1つ変わるだけで、途中呼び出していたモック呼び出しは全て壊れ（エラー）、テストをパスさせるために全て修正することになる。
そりゃ詳細にチェックすればそうなるよなと思いつつ、テストをパス出来るように直すのにプロダクションコード以上の工数が掛かると、流石に何か間違ってないかと思い始める。

また「細かく検証出来る」とは逆に「全く検証しない」ことも出来る。引数の値を検証せず、検証はしないくせにreturnする値を自由に定義することができる。このことは、入力と出力がプログラム上論理的に整合制が取れていないテストを生み出す。こうなるとレビューしていて何が正しいのか、テストがパスしているからいいのか、きちんと正しい値を全てのモックのメソッド呼び出しで整合性を取れるようにレビュー側もチェックして、指摘すべきなのか、そんなに工数使うところなのか混乱する。
細かく検証しているところもあれば、全く検証しないところもあると、違いは何なのか。単に整合性取れたテストコード書くのが大変だから検証しないようにするのだとして、労力に見合う価値があるのか、検証を省く基準は何なのか。

「ドメイン層など処理の流れの下層でテスト網羅しているので、上層ではモックでいい」は果たしてそうなんだろうか。整合性取れてなくてもでっち上げでテストパス出来てしまうし、プロダクションコードで処理を通すべきなのではないか。

この辺りに本の解答としては大まかに、外部に向かうコミュニケーションを模倣するテストダブルをモックといい、モックは外部依存に対して使う。検証方法はブラックボックステストで、外部から観察可能な振る舞いについて検証する。そしてテストコードもプロダクションコード同様に資産ではなく負債と捉え、プロジェクトの持続的な成長を目指すうえで価値のあるテストのみを実装する、とある。

あとがき

「モック」という存在1つ取ってもモヤモヤし続けていたが、この本を読んで大分クリアになった。実務に直結するので活かしていきたい。