脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック

11章ユニットテストを編集する

本書の第Ⅰ部で扱ったプラクティスを使って最初から作ったコードベースはほとんどありません。多くのコードベースは、長いメソッドがあり、複雑度は高く、カプセル化は貧弱で、自動テストのカバレッジは低いです。そのようなコードを私たちはレガシーコードと呼びます。すでに『レガシーコード改善ガイド』[27]という素晴らしい本がありますので、ここで同じことを繰り返すつもりはありません。

11.1　ユニットテストのリファクタリング

信頼できる自動テストスイートがあれば、書籍『リファクタリング』[34]が紹介している多くの教訓を適用できます。この本では、ふるまいを変えることなく既存のコードの構造を変える方法について説明しています。名前の変更、ヘルパーメソッドの抽出、コードの移動など、紹介されているテクニックの多くが最近のIDEに組み込まれています。このトピックについては、他のリソース[34]でかなり深くまで扱っているため、時間を使わないようにします。

11.1.1　セーフティネットの変更

『リファクタリング』[34]では、自動テストスイートのセーフティネットがある場合にプロダクションコードの構造を変更する方法を説明しています。一方で、『xUnit Test Patterns』[66]には、「Refactoring Test Code（テストコードのリファクタリング）」という副題がついています†1。

[†1] 公平のために言っておくと、この本はリファクタリングの本というよりはデザインパターンの本です。

テストコードはプロダクションコードが動作することに自信を持つために書くコードです。私が本書で主張しているように、コードを書いていると簡単に間違えます。では、テストコードに間違いがないことはどうすればわかるでしょうか？ ...