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

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

手作業の確認には、直した箇所とは別の場所が壊れていても気づけない、という弱点がある。
確認する範囲に、そこが入っていないからだ。

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

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

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

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

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

手作業だと、直した箇所の確認しかしなくなりがちだ。
テストコードにすれば、直すたびに、過去に書いた確認も全部まとめて走らせられる。

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

全部にテストを書こうとすると、手が止まる

ありがちな失敗は、全部の機能にテストを用意しようとすることだ。
範囲が広すぎて、いつまでも終わらない。
テストを書く前に力尽きて、書かないまま元に戻る、という話もよく聞く。

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

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

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

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