引き継いだシステムにテストが1本も無い。修正を頼まれても、正しく直ったかどうかは動かして目で見るしかない。10行の変更に半日の確認がついてくる。この状態を変えたくてテストを書こうと決めたとき、最初に詰まるのはどこに書くかです。
カバレッジを指標にすると、書きやすいところから埋めることになります。日付の整形、文字列の変換、金額の丸め。数字は動きますが、明日の修正は怖いままです。1本目に選ぶべきなのは、テストしやすい場所ではなく、手を入れるのが怖い場所です。
次に変更する場所に書く
1本目は、これから変えることが決まっている箇所に書きます。来週の改修で触る関数、障害が出て調査中のバッチ、仕様変更の依頼が来ている画面の処理。すでに変更の予定がある場所です。
理由は単純で、そこに書いたテストだけが今週の役に立つからです。触らない場所のテストは、書いた瞬間から誰も実行しません。変更予定の場所に書けば、その日のうちに「変更前と同じ結果が出ている」という確認に使えます。効果が出るまでの時間が短いほど、次の1本を書く気になります。
変更予定が無い状態でテストを書き始めたなら、直近半年の障害履歴を開きます。同じ場所で2回以上壊れているところがあれば、そこが1本目です。壊れた実績のある場所は、また壊れます。
正しさではなく、いまの出力を記録する
ここで多くの人が止まります。仕様書が無いので、何が正しい結果なのか書けない。書けないままテストを作ろうとして、結局あきらめる。
正しさは後回しにします。いまの入力を通したときに、いまのコードが返す値をそのまま保存して、それと比較するテストにします。実行結果をファイルに書き出しておき、次回以降は保存したファイルと突き合わせるだけ。期待値を人間が考えないので、仕様が分からなくても書けます。
この方法では、いまのバグも正解として固定されます。それでかまいません。目的は正しさの証明ではなく、自分の変更で何かが変わったかどうかを知ることです。バグを直すときは、そのとき保存したファイルを更新します。差分が出て、どこが変わったかが読めます。
つまずくのは、出力に日時や連番やランダム値が混ざっている場合です。実行のたびに差分が出るので、比較する前にその部分を固定値へ置き換えます。ここを面倒がって放置すると、毎回落ちるテストになり、そのうち誰も見なくなります。
データベースを切り離そうとしない
テストの入門書には、外部依存をモックに置き換えると書いてあります。レガシーコードの1本目では、この順番を守らないほうが早く進みます。
SQLが処理の本体に埋まっているコードからDBを剥がすには、先に構造を変える必要があります。テストが無い状態で構造を変えるのは、いちばんやりたくない作業です。順番が逆になっています。最初はDBにつないだまま動かします。
テスト用のデータベースは、本番のスキーマから作ります。軽くしたいからと別のDB製品に置き換えると、方言の違いで通らないSQLが出てきて、そこで半日使います。データは本番の一部を持ってくるか、テストの中で必要な行だけ入れて、終わったら消します。
実行に数分かかっても、最初は許容します。手で確認していた30分が3分になれば十分な改善です。速くするのは、本数が増えて実行が習慣になってからで間に合います。
書いたテストを一度落とす
テストが通ったら、通ったことを疑います。期待値をわざと1文字変えるか、テスト対象のコードに存在しない分岐を足して、赤くなることを確かめます。
この確認を省くと、何もしていないテストを抱えることになります。よくあるのは、対象の処理が内部で例外を握りつぶしていて常に同じ値を返している場合。テストファイルの命名がランナーの規約に合っておらず、そもそも実行されていない場合。呼び出しの引数が足りずに早期リターンして、比較する前に終わっている場合。どれも緑のまま何も検出しません。
落ちることを一度見ておけば、以降その1本は信用できます。信用できる1本があると、次の変更のときに手が動きます。
2本目からの増やし方
1本目が動いたら、同じ処理の分岐を追います。全部ではなく、これから変更する部分に関係する分岐だけです。特定の取引先だけ計算が違う、月末は別の式になる、ある日付より前は旧仕様で動く。こうした例外がそのまま2本目、3本目になります。
境界の値も足します。0件のとき、1件のとき、上限を超えたとき。レガシーコードが壊れるのはたいていこの3か所です。
増やす範囲は、変更する場所の周りで止めます。ついでに隣の機能もと広げると、終わりが見えなくなって改修そのものが遅れます。触らない場所にテストが無いのは、いまの時点では問題になりません。
この段階でやらなくていいこと
カバレッジの計測は要りません。数本しか無い段階で率を出しても、低いという事実が分かるだけで、次の行動が変わりません。
テストコードの整理も後回しでかまいません。準備処理が重複していても、名前が雑でも、動いて落ちるなら役目は果たしています。テストを綺麗にする作業を先に始めると、本来やりたかった改修に届かないまま時間が終わります。
本番のコードをテストしやすい形に直すのも、まだです。それは1本目が守ってくれるようになってから着手する作業です。
どこに書くか決められないまま時間が過ぎているなら、次に修正依頼が来た関数を1本目にします。判断の材料が足りないのではなく、選ぶ基準が無いだけのことが多い。実際に触る場所を選べば、少なくとも無駄にはなりません。
