毎回手で確認していたのをやめた。プログラムにテストをさせる話

スタンプラリーの機能を直したあと、いつも同じ手順で確認していた。
ログインして、スタンプを押して、達成率が上がるか見る。
直すたびに、この手順を繰り返していた。

ある日、直したはずの箇所とは別の場所が壊れていたことに、公開してから気づいた。
手で確認する範囲に、そこが入っていなかった。

確認する手順を、コードにして残しておく

テストコードというものがあるのは知っていた。
なんとなく難しそうで、後回しにしていた。

実際にやってみると、やっていることは手作業の確認と同じだった。
「この関数にこの値を渡したら、この結果が返ってくるはずだ」という確認を、人間が目で見る代わりに、コードに書いておく。

assertEquals(3, calcTotal([1, 1, 1]));
のように、期待する答えをあらかじめ書いておいて、実際の結果とずれていたら教えてもらう。

直すたびに、前の確認も一緒に走らせる

手作業だったころは、直した箇所の確認しかしていなかった。
テストコードにしてからは、直すたびに、過去に書いた確認も全部まとめて走らせるようにした。

これで、直した場所とは関係ないところが壊れていても、確認のときに引っかかるようになった。
公開してから気づく、という順番がなくなった。

全部にテストを書こうとして、手が止まった

最初の失敗は、全部の機能にテストを用意しようとしたことだった。
範囲が広すぎて、何日経っても終わらない。
結局、テストを書く前に力尽きて、書かないまま元に戻ってしまった。

いまは、過去に一度壊れたことのある箇所から書いている。
同じ場所は、また同じ理由で壊れやすい。
壊れた実績のある場所を優先すると、少ない本数でも安心できる範囲が広がった。

テストが赤くなるのは、悪いことではなかった

テストを書き始めたころ、失敗の印（赤色の表示）が出るたびに焦っていた。
いまは、赤くなるのは「直す前に気づけた」というだけのことだと思えるようになった。
公開したあとに赤くなるより、手元で赤くなるほうがずっといい。

確認の手順は、増えるほど覚えていられなくなる。
覚える代わりに、コードに書いて残しておく。
それだけで、直すたびに感じていた不安が、だいぶ減った。