![](https://cdn-ak-scissors.b.st-hatena.com/image/square/79f1f1f8684fc921b808746dfb41c307ceb63580/height=288;version=1;width=512/https%3A%2F%2Fcodezine.jp%2Fstatic%2Fimages%2Farticle%2F4165%2F4165_arena.png)
エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
「レガシーコード改善ガイド」のススメ 第4回:既存のコードに極力手を加えずにテストで保護する
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
「レガシーコード改善ガイド」のススメ 第4回:既存のコードに極力手を加えずにテストで保護する
既存のコードをテストで保護する 前回の記事では「スプラウトクラス」(Sprout Class)という手法を紹介... 既存のコードをテストで保護する 前回の記事では「スプラウトクラス」(Sprout Class)という手法を紹介しました。これは、レガシーコードに機能を追加する際に、既存のコードにはほとんど手を加えず、新機能を実現するために新しいクラスを作るという手法でした。この手法の基本にあるのは、既存のコードにテストを書くことはあきらめるとしても、せめて新しく書いたコードだけはテストで保護しよう、という考え方です。 こうした手法は時間が少ない状況で新しい機能を追加する際に有効です。しかしこれを使い続ける限り、いつまで経っても既存のコードは改善しません。 そこで、既存のコードをテストで保護する手法が必要になります。『レガシーコード改善ガイド』では、こうした手法が数多く紹介されています。今回の記事では、その中のもっとも基本的な手法の1つを紹介しましょう。 テストが困難な既存コードの例 ここでは、あるスーパー