テストで保護することができない場合
レガシーコードに手を加える場合、テストで保護することが何よりも大切であることは、これまでの連載で説明してきました。ですが、レガシーコードにテストを用意することはなかなか大変なことも事実です。
テストを用意するためには、テスト対象となるクラスのインスタンスを作らなければなりませんが、依存関係が複雑だったり、コンストラクタの引数にたくさんの別のインスタンスが必要だったりすると、とたんに困難な作業になります。
そのようなクラスに機能を追加しなければならなくなったとしたらどうすればよいでしょうか？ 十分に時間があれば、対象とするコードに対してリファクタリングを行い、テストを準備してから取り掛かりたいところです。しかし、機能追加の規模が小さいと、大規模なリファクタリングをする時間などありません。だからといって、テストで保護せずに作業してしまうことはレガシーコード状態を続けることになります。
このような状況はよくあるのではないでしょうか。
「テストを用意した方が良いことはよくわかっているけど、 実際にはそんな時間はないんだよね……」
『レガシーコード改善ガイド』では、このような現実に対して、いくつかの対処手法が紹介されています。理想論だけが語られる書籍が多いなかで、とても珍しいことです。今回は、この本で紹介されている数多くの手法のなかから、スプラウトクラスという手法を紹介します。
