テストがないコードはレガシーコード

やっと読み終えました。

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

この本は、「先人達が残していった遺産に対して変更を加えなければならない」場合の
大きな助けになります。リファクタリングの観点から見ても中々学ぶことが多いです。

本書では、レガシーコードの定義として
「テストがないコード」と言っています。
テストがないコードはレガシーコードと言えるでしょうが、
私個人的には、『自分が書いていないけど押し付けられたコード』もレガシーコードと
呼ばれてる気がします。
自分にとってわかりづらいという理由で。

保守や改修案件なんかで人の作ったソースコードを見て改修する時なんか
そう思うかもしれませんが、そりゃそうですよね。
初見でわかるようなロジック組んでる訳じゃないんだから。
その人がわかりやすいと思うシグネチャ設計もまちまちなら
通ってきた現場の文化もまちまちなわけですから。

新規で作られた時にはわかりやすかったかもしれませんが、
いろんな人に手を加えられたソースコードに対して
初見だけで全てを理解するだなんて、本当にスキルがある人でないと
できないわけです。
それも、この手の仕事を進んでやりたがる人も少ない。

気に入らないからリファクタ(というか全とっかえ)しようにも
時間やコストが無いからそれもできない。

多分、あなたが書いたソースコードはあなたが思うほど
他人に理解されていないはずです。
クラス設計やロジックに対する補足資料としてドキュメントがあれば
まだ理解される可能性がありますが、そのドキュメントは
メンテナンスされていますか？

私はドキュメントは大事だと思っていますが、
実装寄りの場合は、それよりもテストクラスが重要だと思っています。*1
実際にシステムはそのソースコードで動いているわけですから
仕様を記述しているドキュメントよりもクラス図よりも
そのソースコードに対するテストクラスが一番信頼できます。

かつ、他人が書いたソースコードでも振る舞いレベルであれば
テストクラスが担保します。
リファクタリングを行う際にも恐れることはありません。
ただ、テストクラスで記述されていない箇所は担保できないので
不足しているものについてはメソッドを追記していく必要があります。
ここで注意しなければならないのは、容易にテストメソッドの結果比較部分を
書き換えないことです。
テスト対象クラスの振る舞いにテストクラスを合わせてしまえば
テストケースが通るのは当たり前です。
テストクラスの変更は、本当に書き換えても良いか細心の注意を払わなければ
テストの意味がなくなってしまいます。
『答え』を自分の回答に合わせて変更して100点を取ったテストに何の意味があるのでしょう？

ただ、テストケースの追加はどんどん行うべきです。
単体テスト時だけでなく、結合/総合テスト時に出たバグに対する
テストケースを追加することでそのテストクラスの存在価値が上がっていきます。
前回修正したはずのバグが、別の対応によって再発生したことを抑えることもできるのです。
テストクラスのレベルを上げていけばより頼もしい相棒になるはずです。
しかもその相棒は相手によって贔屓することを知りません。誰に対しても頼もしいのです！

という訳で、単体テストの書き方の参考に*2

経験ゼロでもできるプログラミング現場の単体テスト

*1:ドキュメントはユーザとの認識あわせ

*2:結局自分の本の紹介だったりする