無法地帯にテストケースを追加する時にいつもやっている戦略

数年開発続いてるけどテスト全くないみたいなよくあるコードベースを想定。

不具合を修正する時についでにリファクタリングしてドメイン層のテストを書く。

  1. 手動テストで不具合を再現
  2. ViewからロジックをControllerへ移動し、Viewからは値の参照のみにする
  3. 移動したロジックをController内でプライベートメソッドに切り出す。返り値を(2)の値にセットする
  4. プライベートメソッドを外に出して関数→モジュール化する
  5. (4)のメソッドに対してテストを書き、失敗するのを確認する

ポイントとしては

  • 運用的観点ではなるべく早く不具合を修正してデプロイしたいので、リファクタリングだけ別のブランチでゆっくりやる
  • 依存がでか過ぎで解決できなさそうなど問題があれば、その時点ではテストを書くのを諦める。行動したことで学んだIssueを起票する

具体的なリファクタリング方法は

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコード改善ガイド (Object Oriented SELECTION)

  • 作者: マイケル・C・フェザーズ,ウルシステムズ株式会社,平澤章,越智典子,稲葉信之,田村友彦,小堀真義
  • 出版社/メーカー: 翔泳社
  • 発売日: 2009/07/14
  • メディア: 大型本
  • 購入: 45人 クリック: 673回
  • この商品を含むブログ (157件) を見る
とか
新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

とか

テストケースが蓄積されるとリアーキテクチャリングにも手を出しやすい

レガシーソフトウェア改善ガイド

レガシーソフトウェア改善ガイド

けど現実ではエイヤで全部捨てるプロジェクトが多くてもったいないなーと思っていた。