テストコードをなぜ、書く必要があるのか、について考察。
深く考えずに、工数削減と思っていたが、それ以外のメリットの方が重要なのではないか。
そもそも、なぜテストコードは工数削減になると思ったのか？
テストは工数がかかるものである。
小さなサービスのうちはよいが、ある程度、機能が増えてくると、その一つ一つを手動で確認するのは、困難になる。そのため、テストコードを書いておけば、繰り返し実施するテストについては、毎回、手を動かす必要はなく、その点においては、確かに工数削減になっていると思う。
しかし、webの記事を読んでいても、テストコードを工数削減の文脈で語られていることは少ないと感じる。
なぜなら、テストコードは一度書けば終わり、というものではなく、プログラムの変化に伴い、運用していかなければならないものであり、その分の工数は増えてしまうという側面がある。
テストコードを工数削減のために書く、という考えは、浅すぎるように思える。
なぜ、テストコードを書いたほうがいいのか？
テストコードは運用をしていくものであり、開発工数は増加する。
テストの手作業分の工数を差し引いて、総合的な工数が削減される、という理屈は、感覚的にも信じられない。
では、なぜ、テストコードを書くべきか？を考えたときに思いあたるのは以下の通り。
- 再現性を持たせることで、必要な機能の動作を網羅的に担保することができる。
- 開発者の意図を残せる。
- ソースコードという組織としてのナレッジが溜まる。
特に後者二つについては、なかなか、効果を可視化はしにくいものの、思っている以上に効果のあるものではないかと思える。
0からサービスのプログラムを書く、という経験は珍しいのではないかと思われるが、誰かの書いたソースコードを引き継いで、開発を行うとき、機能のどのような動きが肝であるのか、を残すことはとても重要なことである。
どういう経緯で作られ、仕様・要件はこうで、というドキュメントは残されているだろうが、そういったドキュメントを更新し続けることは、現実的には難しいと思われる。
テストコードが特別、他のドキュメントよりも更新しやすいとは思わないが、開発者自身が行うタスク（テスト）とセットになっていることから、自分事になりやすいという側面はあるのではないか。
開発者目線では、ソースコードを読むことで理解できることは、大きなメリットがある。
テストコードを工数削減という目線で考えるよりも、組織的ナレッジを長期に渡って残すため、という目線で考えるほうが、正しいのではないかと思う。