こちらの会を聴いたので、見て印象的だった部分とその部分に対しての感想を書いていこうと思います。
レガシーコードに対してテストを書く行為について
テストを書きながら開発するプロダクションコードに比べ、レガシーコード(テストがないコード)に対してテストを書きながら開発する方が難度が高い*1ということで、レガシーコードにテストを書くためのコツを聴くことができました。
基本的には、E2Eを外側から書いていって正常系はテストできているような状態にするorテストが書けるような構造になるように内部に穴をあけていくという作戦を合わせていくという話でした。
また、この作戦をどこからやっていくのか優先順位を決める時は、影響範囲の大きさ×ビジネス価値の高さと、実際に不具合が出ているかどうかといった視点で決めていくということでした。
優先順位の決め方をt_wadaさんがどうしているかだったり、「こうあるべき」という姿よりも今何が起きているのか(不具合が起きている、～というテストを書いたら機能が壊れた...)に注目するという話は、t_wadaさんが普段どのように意思決定されているかを知れたという意味で非常に有意義でした。
また、レガシーコード改善ガイドを改めて読み直したいと思いました。
テストの消し方
前提として、コミットのコメントやチケットなどにテストの意図が書いてあるかないかで大分難度が変わってくるということでした。*2
テストの意図があれば、何を消せばいいのか分かるので大分楽になるものの、そうでない場合も多いので、意図がない時は、同時に失敗するテストたちが出てきた時に消せないかと考えたり、カバレッジを基に判断する方法が定跡としてあるということでした。
ただ、カバレッジは研究半ばで機械による判別がまだできていない課題があったり、テストが同時にこけた時もテストを一部消していいとは一概に言えないということもあり、ボーイスカウトルールやペアプロで消すテストを選定していくのがなんだかんだおすすめということでした。
テストダブルを積極的に使うか(モックをテストにどう使うか)
TDDする際にテストダブルを積極的に使うといいかどうか？というお話をしていきました。
クラシック派とモッキスト派に分かれるというお話から始まり、t_wadaさんはクラシック派のスタイルを取っているが、これはあくまでもスタイルの話で、どちらが正解か不正解かという話はないという注意の基、クラシック派にt_wadaさんがなった経緯を伺うことができました。
t_wadaさんも元々はモッキスト派で、がんがんモックを使いながらテストを書くことが多かったということですが、モックしてテストを通したはいいものの自分が想定している通りに実際には動かない現実(DBなど)を間のあたりにして、自分のプログラミング能力を信頼しないという策略を考えることになり、古典派としてなるべくモックを使わないスタイルでプログラミングするようになったということでした。
なお、前述した通り、クラシック派でもモッキスト派でもどちらが正解という話はないのですが、モッキスト派を誤解してしまった例として、テスト容易性が低いレガシーコードに対して無理やりモックでテストを書いてOKという人が出てしまっているようで、これは明らかにモックの本来の使い方を取り違えているので注意した方がいいというお話でした。
全体を通した感想
前半後半を通して、テストももちろんですが、ソフトウェア開発の原理原則を丁寧に抑えておくことの重要性を実感しました。
最後にt_wadaさんから、サバンナを生きて抜いていくための心構えが聴けたのも印象的でした。
前編後編ともに、現場のリアルな悩みに対してt_wadaさんがどのように考えていくのか、という思考過程がみれたのが最高でした！
